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Abstract 


Most  specifications  of  garbage  collectors  concentrate  on  the  low-level  algorithmic  details  of  how  to 
find  and  preserve  accessible  objects.  Often,  they  focus  on  bit-level  manipulations  such  as  “scanning 
stack  frames,”  “marking  objects,”  “tagging  data,”  etc.  While  these  details  are  important  in  some 
contexts,  they  often  obscure  the  more  fundamental  aspects  of  memory  management:  what  objects 
are  garbage  and  why? 

We  develop  a  series  of  calculi  that  are  just  low-level  enough  that  we  can  express  allocation 
and  garbage  collection,  yet  are  sufficiently  abstract  that  we  may  formally  prove  the  correctness  of 
various  memory  management  strategies.  By  making  the  heap  of  a  program  syntactically  apparent, 
we  can  specify  memory  actions  as  rewriting  rules  that  allocate  values  on  the  heap  and  automatically 
dereference  pointers  to  such  objects  when  needed.  This  formulation  permits  the  specification  of 
garbage  collection  as  a  relation  that  removes  portions  of  the  heap  without  affecting  the  outcome  of 
the  evaluation. 

Our  high-level  approach  allows  us  to  compactly  specify  and  prove  correct  a  wide  variety  of 
memory  management  techniques,  including  standard  trace-based  garbage  collectors  [i.e.,  the  family 
of  copying  and  mark/sweep  collectors),  generational  collection,  and  type-based  tag-free  collection. 
Furthermore,  since  the  definition  of  garbage  is  based  on  the  semantics  of  the  underlying  language 
instead  of  the  conservative  approximation  of  inaccessibility,  we  are  able  to  specify  and  formally 
prove  the  idea  that  type  inference  can  be  used  to  collect  some  objects  that  are  accessible  but  never 
used. 


1  Memory  Safety 

Advanced  programming  languages  manage  memory  allocation  and  deallocation  automatically.  Au¬ 
tomatic  memory  managers,  or  garbage  collectors,  significantly  facilitate  the  programming  process 
because  programmers  can  rely  on  the  language  implementation  for  the  delicate  tasks  of  finding  and 
freeing  unneeded  objects.  Indeed,  the  presence  of  a  garbage  collector  ensures  memory  safety  in  the 
same  way  that  a  type  system  guarantees  type  safety:  no  program  in  an  advanced  programming  lan¬ 
guage  will  crash  due  to  dangling  pointer  problems  while  pointer  allocation,  access,  and  deallocation 
is  transparent.  However,  in  contrast  to  type  systems,  memory  management  strategies  and  particu¬ 
larly  garbage  collectors  rarely  come  with  a  compact  formulation  and  a  formal  proof  of  soundness. 
Indeed,  since  garbage  collectors  work  on  the  machine  representations  of  abstract  values,  the  very 
idea  of  providing  a  proof  of  memory  safety  sounds  unrealistic  given  the  lack  of  simple  models  of 
memory  operations. 

The  recently  developed  syntactic  approaches  to  the  specification  of  language  semantics  by 
Felleisen  and  Hieb  [11]  and  Mason  and  Talcott  [23,  24]  are  the  first  execution  models  that  are 
intensional  enough  to  permit  the  specification  of  memory  management  actions  and  yet  are  suffi¬ 
ciently  abstract  to  permit  compact  proofs  of  important  properties.  Starting  from  the  A^-S  calculus 
of  Felleisen  and  Hieb,  we  design  compact  specifications  of  a  number  of  memory  management  ideas 
and  prove  several  correctness  theorems. 

The  basic  idea  underlying  the  development  of  our  garbage  collection  calculi  is  the  representation 
of  a  program’s  run-time  memory  as  a  global  series  of  syntactic  declarations.  The  program  evaluation 
rules  allocate  large  objects  in  the  global  declaration,  which  represents  the  heap,  and  automatically 
dereference  pointers  to  such  objects  when  needed.  As  a  result,  garbage  collection  can  be  specified 
as  any  relation  that  removes  portions  of  the  current  heap  without  affecting  the  result  of  a  program’s 
execution. 

In  Section  2,  we  present  a  small  functional  programming  language.  Age,  with  a  rewriting  seman¬ 
tics  that  makes  allocation  explicit.  In  Section  3,  we  define  a  semantic  notion  of  garbage  collection 
for  Age  and  show  that  there  is  no  optimal  collection  strategy  that  is  computable.  In  Section  4,  we 
specify  the  “free-variable”  garbage  collection  rule  which  models  tracing-based  collectors  including 
mark/sweep  and  copying  collectors.  We  prove  that  the  free- variable  rule  is  correct  and  provide  two 
“implementations”  at  the  syntactic  level:  the  first  corresponds  to  a  copying  collector,  the  second 
to  a  generational  one.  In  the  context  of  generational  collection,  we  also  illustrate  how  mutable 
reference  cells  render  the  original  generational  collector  unsound  and  how  the  problem  can  be  fixed 
at  an  abstract  level. 

In  Section  5,  we  show  how  the  use  of  abstract  syntax  facilitated  our  work  in  the  first  few  sections. 
Specifically,  the  abstract  syntax  of  Age  implicitly  carries  the  shape  (size  and  pointer  information) 
of  allocated  objects,  which  permits  specifications  of  GC  algorithms  that  ignore  the  problem  of 
traversing  the  memory  graph  in  the  absence  of  guiding  information.  To  illustrate  how  to  refine 
Age  just  enough  to  address  this  problem,  we  formalize  so-called  “tag-free”  collection  algorithms 
for  explicitly- typed,  monomorphic  languages  such  as  Pascal  and  Algol  [7,  36,  8].  We  show  how  to 
reconstruct  necessary  shape  information  about  values  from  types  during  garbage  collection.  We 
are  able  to  prove  the  correctness  of  the  garbage  collection  algorithm  by  using  a  well  known  type 
preservation  argument.  We  then  sketch  how  the  type-based  garbage  collection  algorithms  can  be 
extended  to  a  language  with  a  polymorphic  type  system  in  the  style  of  the  Girard-Reynold’s  System 
F  [13,  14,  30].  Our  formulation  leads  to  a  fairly  simple  proof  of  the  correctness  of  Tolmach’s  garbage 
collector  for  the  Gallium  ML  compiler  [34]. 

In  Section  6,  we  justify  our  semantic  definition  of  garbage  by  showing  that  Milner-style  type 
inference  can  be  used  to  prove  that  an  object  is  semantically  garbage  even  though  the  object  is  still 
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reachable.  While  previous  authors  have  sketched  this  idea  [6,  3,  16,  12],  we  are  the  first  to  present 
a  formal  proof  of  this  result.  The  proof  is  obtained  by  casting  the  well-known  interpretation  of 
types  as  logical  relations  into  our  framework. 

Section  7  discusses  related  work  and  Section  8  closes  with  a  summary. 


Programs: 


(variables) 

x,y,z 

G 

Var 

(integers) 

i 

G 

Int  : 

:=  ...  1  -  2  1  -1  1  0  1  1  1  2  1  ■■■ 

(expressions) 

e 

G 

Exp  : 

:=  a;  1  i  1  (61,62)  |  tti  e  |  712  e  |  \x.e  |  ei  62 

(heap  values) 

h 

G 

Fival  : 

:=  i  1  {x-i_,X2)  1  \x.e 

(heaps) 

H 

G 

Heap 

. —  —  h\, . , . ,  Xfi  —  h-fi^ 

(programs) 

P 

G 

Prog 

:=  letrec  F  in  6 

(answers) 

A 

G 

Ans  : 

:=  letrec  F  in  x 

Evaluation  Contexts  and  Instruction  Expressions: 

(contexts)  E  G  Ctxt  ::=  [  ]  |  {E,e)  \{x,E)\'KiE\Ee\xE 

(instructions)  I  G  Instr  ::=  h  \  iTi  x  \  x  y 

Figure  1:  The  Syntax  of  Age 


2  Modeling  Allocation:  Age 

Syntax:  The  syntax  of  Age  (see  Figure  1)  is  that  of  a  conventional,  higher-order,  applicative 
programming  language  based  on  the  A-calculus.  Following  the  tradition  of  functional  programming, 
a  Age  program  (P)  consists  of  some  mutually  recursive  definitions  {H)  and  an  expression  (e).  The 
global  definitions  are  useful  for  defining  mutually  recursive  procedures,  but  their  primary  purpose 
here  is  to  represent  the  run-time  heap  of  a  program.  In  general,  there  can  be  cycles  in  a  heap  so 
we  use  letrec  instead  of  let  as  the  binding  form.  Expressions  are  either  variables  (a;),  integers  (i), 
pairs  ((61,62)),  projections  (tt,),  abstractions  (Ax.e),  or  applications  (ei  62). 


FV{i) 
FV{x) 
FF((ei,e2)) 
FV{TTi  e) 
FV{\x.e) 
FF(ei  62) 


=  0 

=  FF(ei)UFF(e2) 
=  Fv{e) 

=  FVie)\{x} 

=  FV{ei)  U  FVieo) 


FV{{xi  =  hi,...,Xn  =  h„})  =  (Fy(/ii)U...UFF(/i„))\{xi,...,a;„} 

FF(letrec  F  in  e)  =  (FF(F)  U  FF(e))  \  Dom{H) 


Figure  2:  Calculating  Free  Variables 


Formally,  the  heap  is  a  series  of  pairs,  called  bindings,  consisting  of  variables  and  heap  values. 
Heap  values  are  a  semantically  significant  subset  of  expressions.  The  order  of  the  bindings  is 
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irrelevant.  In  addition,  each  variable  must  be  bound  to  at  most  one  heap  value  in  a  heap.  Hence, 
we  treat  heaps  as  sets  and,  when  convenient,  as  finite  functions.  We  write  Dom{H)  to  denote  the 
bound  variables  of  H  and  Rng{H)  to  denote  the  heap  values  bound  in  H.  We  sometimes  refer  to 
variables  bound  in  the  heap  as  locations  or  pointers. 

The  language  contains  two  binding  constructs:  \x.e  binds  a;  in  e  and  letrec  H  \n  e  binds  the 
variables  in  Dom{H)  to  the  expressions  Rng{H)  in  both  the  values  in  Rng[H)  and  in  e.  Following 
convention,  we  consider  expressions  to  be  equivalent  up  to  a  consistent  a-conversion  of  bound 
variables.  The  free  variables  of  expressions,  heaps,  and  programs  are  determined  by  the  definitions 
of  Figure  2. 

Considering  programs  equivalent  modulo  o'-conversion  and  the  treatment  of  heaps  as  sets  instead 
of  sequences  hides  many  of  the  complexities  of  memory  management.  In  particular,  programs  are 
automatically  considered  equivalent  if  the  heap  is  re-arranged  and  locations  are  re-named  as  long 
as  the  “graph”  of  the  program  is  preserved.  This  abstraction  allows  us  to  focus  on  the  issues 
of  determining  what  bindings  in  the  heap  are  garbage  without  specifying  how  such  bindings  are 
represented  in  a  real  machine. 

Mathematical  Notation:  We  use  W  1+)  W'  to  denote  the  union  of  two  disjoint  sets,  X  and  X'. 
We  use  H  H'  to  denote  the  union  of  two  heaps  whose  domains  are  disjoint.  We  use  {ei/a:}e2  to 
denote  capture-avoiding  substitution  of  the  expression  ey  for  the  free  variable  x  in  the  expression 
62-  We  use  W  \  W'  to  denote  {x  ^  X  \  x  ^  X'}. 

Semantics:  The  rewriting  semantics  for  Age  is  an  adaptation  of  the  standard  reduction  function 
of  the  A,;-S  calculus  [11].  Roughly  speaking,  this  kind  of  semantics  describes  an  abstract  machine 
whose  states  are  programs  and  whose  instructions  are  relations  between  programs.  The  desired 
final  state  of  this  abstract  machine  is  an  answer  program  {A)  whose  body  is  a  pointer  to  some 
value,  such  as  an  integer,  in  the  heap. 

Each  rewriting  step  of  a  program  letrec  H  in  e  proceeds  according  to  a  simple  algorithm.  If 
the  body  of  the  program,  e,  is  not  a  variable,  it  is  partitioned  into  an  evaluation  context  E  (an 
expression  with  a  hole  C  ]  in  the  place  of  a  sub-expression),  which  represents  the  control  state, 
and  an  instruction  expression  I,  which  roughly  corresponds  to  a  program  counter:  e  =  £'[/].  The 
instruction  expression  determines  the  next  expression  e'  and  any  changes  to  the  heap  resulting  in 
a  new  heap  H' .  Putting  the  pieces  together  yields  the  next  program  in  the  evaluation  sequence: 
letrec  H'  in  £l[e'].  Each  instruction  determines  one  transition  rule  of  the  abstract  machine.  For¬ 
mally,  a  rule  denotes  a  relation  between  programs.  A  set  of  rules  denotes  the  union  of  the  respective 
relations. 

We  use  the  following  conventions:  Let  G  be  a  set  of  program  relations,  and  let  P  and  P'  be 
programs.  Then, 

P  h-^  P'  means  P  rewrites  to  P'  according  to  one  of  the  rules  in  G  and  h-^*  is  the  reflexive, 

transitive  closure  of  i-^. 

G  -b  c  is  the  union  of  G  with  the  rule  r. 

A  program  P  is  canonical  with  respect  to  G  iff  there  is  no  rule  in  G  and  no  P'  such  that 

P^P’. 

P  Jj-G  P'  means  that  F  \-P^*P'  and  P'  is  canonical  with  respect  to  G. 

P  ffG  means  that  there  exists  an  infinite  sequence  of  programs  Pi  such  that  P  Py 

F2  ^ 
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Figure  1  defines  the  set  of  evaluation  contexts  and  instruction  expressions  for  Age.  The  definition 
of  evaluation  contexts  {E)  reflect  the  left-to-right  evaluation  order  of  the  language.  All  terms  to 
the  left  of  the  path  from  the  root  to  the  hole  are  variables;  the  terms  on  the  right  are  arbitrary. 
Instruction  expressions  (7)  consist  of  heap  values  (fi),  applications  of  (pointers  to  heap- allocated) 
procedures  to  (pointers  to  heap-allocated)  values,  and  projections  of  (pointers  to  heap-allocated) 
tuples. 


(alloc)  letrec  H  in  £'[/i]  letrec  7f  l±l  {a;  =  A}  in  jBCx] 

(proj)  letrec  H  in  FEtt,-  x]  letrec  H  in  Elxil  (77(x)  =  {xi,X2)  and  i  =  1,2) 

(app)  letrec  i7  in  FCx  ?/]  letrec  77  1+)  {2:  =  i7(?/)}  in  FEe]  {H{x)  =  Xz.e) 


Figure  3:  Rewriting  Rules  for  Age 


The  evaluation  rules  for  Age  (see  Figure  3)  reflect  the  intentions  behind  our  choice  of  instruction 
expressions.  The  transition  rule  alloc  models  the  allocation  of  values  in  the  heap  by  binding  the 
value  to  a  new  variable  and  using  this  variable  in  its  place  in  the  program.  Note  that  the  “!+)” 
notation  carries  the  implicit  requirement  that  the  newly  allocated  variable  x  cannot  be  in  the 
domain  of  the  heap  77.  The  transition  proj  specifies  how  a  projection  instruction  extracts  the 
appropriate  component  from  a  pointer  to  a  heap-allocated  pair.  Similarly,  app  is  a  transliteration 
of  the  conventional  /3-value  rule  into  our  modified  setting.  It  binds  the  formal  parameter  of  a 
heap-allocated  procedure  to  the  value  of  the  pointer  given  as  the  actual  argument,  and  places  the 
expression  part  of  the  procedure  into  the  evaluation  context.  Multiple  applications  of  the  same 
procedure  require  a-conversion  to  ensure  that  the  formal  parameter  does  not  conflict  with  bindings 
already  in  the  heap^.  We  use  R  to  abbreviate  the  union  of  the  rules  alloc,  proj,  and  app. 

As  a  simple  example  of  evaluation  under  72,  consider  rewriting  the  program  P  —  letrec  {x  = 
1}  in  (Ay.TTi  y){x,x): 

letrec  {x  —  l,z  =:  Aj/.tti  y}  in  2  (x,  x) 
letrec  {x  =  z  =  Xy.iTi  y,  w  =  (x,  x)}  \n  z  w 

letrec  {x  =  1,  2  =  Aj/.tti  y,w  =  (x,  x),  y  =  (x,  x)}  in  ttj  y 

letrec  {x  =  1,  x  =  Ay.TTi  y,w  —  (x,  x),  y  =  (x,  x)}  in  x 

We  can  break  P  into  an  evaluation  context  F/q  =  C  ]  x)  and  instruction  Iq  =  Xy.iri  y.  Since  Iq  is  a 

heap  value,  alloc  applies.  We  choose  a  new  variable  x,  bind  the  heap  value  to  x,  and  replace  it  with  x 
in  the  hole  of  Eq^  resulting  in  the  program  letrec  {x  =  1,  x  =  Ay.rri  y}  in  x  (x,  x).  This  program  can 
be  broken  into  evaluation  context  E\  =  z\_'\  and  instruction  7i  =  (x,  x).  7i  is  also  a  heap  value,  so 
alloc  applies,  we  choose  a  new  variable  w,  bind  the  heap  value  to  w,  and  replace  the  instruction  with 
w,  resulting  in  the  program  letrec  {x  =  l,x  =  Xy.ni  y^w  =  {x,x)}  in  x  w.  This  program  can  be 
broken  into  an  empty  context  {E2  =  C  ])  and  instruction  I2  =  z  w.  Since  x  is  bound  to  a  procedure 
and  w  is  bound  in  the  heap,  app  applies.  The  heap  value  that  w  is  bound  to  ((x,x))  is  bound  to 
the  formal  argument  of  the  procedure  (y)  in  the  heap  and  the  body  of  the  procedure  replaces  the 
instruction,  resulting  in  the  program  letrec  {x  =  1,  x  =  Xy.ni  y,w  =  (x,  x),  y  =  (x,  x)}  in  tti  y.  This 
program  can  be  broken  into  an  empty  evaluation  context  (JF3  =  [  ])  and  instruction  I3  =  tti  y. 
Since  y  is  bound  to  a  pair,  the  proj  rule  applies  and  the  instruction  is  replaced  with  the  first 

^An  alternative  rule  for  application  substitutes  the  actual  argument  (y)  for  the  formal  (z)  within  e  and  performs 
no  allocation.  This  rule  is  essentially  equivalent  to  app,  but  the  definition  above  simphfies  the  proofs  of  Section  6. 


letrec  {x  =  1}  in  (Xy.TTi 


y)(x,x) 


alloc 

alloc 
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component  of  the  pair,  namely  x,  resulting  in  the  answer  program  letrec  {x  =  l,z  =  Aj/.tti  y,w  = 
{x,  x),y  =  {x,  x)}  in  x. 

The  canonical  programs  of  Age  are  either  answers  or  stuck  programs.  The  latter  correspond 
to  machine  states  that  result  from  the  misapplication  of  primitive  program  operations  or  unbound 
variables. 

Definition  2.1  (Stuck  Programs)  A  program  is  stuck  if  it  is  of  one  of  the  following  forms: 

•  letrec  H  in  E'Ett,'  x']  [x  ^  Dom{H)  or  H{x)  ^  or 

•  letrec  H  \n  Eix  y]  [x  or  y  ^  Dom{H)  or  H{x)  ^  Xz.e). 

All  programs  either  diverge  or  evaluate  to  an  answer  or  a  stuck  program.  Put  differently,  the 
evaluation  process  defines  a  partial  function  from  Age  programs  to  canonical  programs  [11,  37]. 

Theorem  2.2  If  P  is  a  closed  program,  then  there  exists  at  most  one  P'  such  that  P  P' ■ 

Proof  (sketch):  The  theorem  relies  on  the  following  lemma  which  shows  that  at  each  evaluation 
step,  the  instruction  expression  is  uniquely  determined. 

Lemma  2.3  (Unique  Decomposition)  If  P  —  letrec  if  in  e  is  a  Xgc  program,  then  either  P  is 
stuck,  P  is  an  answer,  or  else  there  exists  a  unique  evaluation  context  E  and  instruction  I  such 
that  e  =  E  [/] . 

Proof  (sketch):  We  show  by  induction  on  the  structure  of  e  that  either  e  is  a  variable  or  there 
exists  a  unique  E  and  /,  such  that  e  =  EIH.  Here,  we  give  one  case  of  the  induction  as  an  example: 
suppose  e  =  (ei  e^)-  There  are  four  cases  to  consider.  If  ei  is  not  a  variable,  then  by  induction, 
there  exists  an  E',  I,  such  that  ei  =  £'^[7],  in  which  case  we  take  E  =  E'  e2-  If  ei  is  a  variable, 
then  ex  =  X  for  some  x  and  H (x)  =  Xz.e'  else  e  would  be  stuck.  Suppose  62  is  not  a  variable.  Then 
by  induction,  62  =  E'lU  and  we  can  take  E  =  x  E'.  Otherwise,  62  =  y  and  we  can  take  £  =  C  ] 
and  /  =  {ex  02).  Other  cases  follow  similarly.  O 

The  rest  follows  from  the  lemma  in  a  straightforward  manner,  given  that  P  is  closed.  □ 


3  A  Semantic  Definition  of  Garbage 

Since  the  semantics  of  Age  makes  the  allocation  of  values  explicit,  including  the  implicit  pointer 
dereferencing  in  the  language,  we  can  also  define  what  it  means  to  garbage  collect  a  value  in  the 
heap  and  then  analyze  some  basic  properties.  A  binding  x  =  hin  the  heap  of  a  program  is  garbage 
if  removing  the  binding  has  no  “observable”  effect  on  running  the  program.  In  our  case,  we  consider 
only  integer  results  and  non-termination  to  be  observable. 

Definition  3.1  (Kleene  Equivalence)  (£i,<Ti)  ~  (£2,^2)  means  Px  U-Gi  letrec  Hx  in  x  where 
Hx{x)  =  i  if  and  only  if  P2  JJ-Gj  'etrec  £2  in  y  and  H2{y)  -  i-  If  Gx  =  G2  =  R,  then  we  simply 
write  Pi  ~  £2. 

A  binding  is  garbage  if  removing  it  results  in  a  program  that  is  Kleene  equivalent  to  the  original 
program: 

Definition  3.2  (Garbage)  Given  a  program  P  =  letrec  if  1+1  {a;  =  h}  in  e,  the  binding  x  =  h  is 
garbage  with  respect  to  P  iff  P  cz:  letrec  if  in  e. 
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A  collection  of  a  program  is  the  same  program  with  some  garbage  bindings  removed.  An  optimal 
collection  of  a  program  is  a  program  with  as  many  garbage  bindings  removed  as  possible. 

Definition  3.3  (Collection,  Optimal  Collection)  The  program  letrec  H  in  e  is  a  collection  of 
P  =  letrec  t+)  i?'  in  e  iff  all  bindings  x  =  h  in  H'  are  garbage  with  respect  to  P.  The  program 
letrec  if  in  e  is  an  optimal  collection  of  P  iff  no  binding  in  H  is  garbage  with  respect  to  P. 

Unfortunately,  there  can  be  no  optimal  garbage  collector  because  determining  whether  a  binding 
is  garbage  or  not  is  undecidable. 

Proposition  3.4  (Garbage  Undecidable)  Determining  if  a  binding  is  garbage  in  an  arbitrary 
closed  Xgc  program  is  undecidable. 

Proof:  Since  Age  is  essentially  an  untyped  A-calculus,  determining  whether  an  arbitrary  closed 

program  P  =  letrec  H  \n  e  halts  with  an  answer  or  not  is  undecidable.  Assume  that  GC  is  an 
algorithm  for  determining  whether  or  not  some  binding  in  the  heap  is  garbage.  Then,  in  particular, 
GC  can  tell  whether  or  not  x  =  {xi.,X2)  is  garbage  in  the  program: 

P'  —  letrec  H  1+1  {a;i  —  l,X2  —  2,x  =  (xi,  0:2)}  'n  (Ay.Trj  x)  e 

where  x  does  not  occur  in  Dom{H).  We  will  show  that  GC  claims  that  the  binding  for  x  is  garbage 
if  and  only  if  P  terminates  with  an  answer,  which  proves  that  GC  cannot  exist. 

Assume  GC  claims  the  binding  for  x  is  garbage.  Then,  the  program  letrec  H  in  (Ax/.tti  x)e  is 
Kleene  equivalent  to  P' ,  which  clearly  implies  that  P'  either  diverges  or  gets  stuck,  because  this 
program  will  always  either  diverge  or  get  stuck.  To  see  this,  note  that  evaluation  will  become  stuck 
when  X  is  dereferenced  by  the  projection  operation.  Given  an  infinite  sequence  of  reduction  steps 
for  P' .  we  can  easily  produce  an  infinite  sequence  of  reduction  steps  for  P,  since  this  sequence  must 
occur  while  evaluating  e.  Similarly,  given  a  sequence  of  reduction  steps  which  takes  P'  to  a  stuck 
program,  we  can  produce  a  sequence  of  reduction  steps  that  causes  P  to  become  stuck,  because  P' 
must  become  stuck  while  evaluating  e,  since  x  is  still  bound  in  P' .  Consequently,  if  GC  claims  x  is 
garbage,  then  P  either  diverges  or  gets  stuck. 

Now  assume  GC  claims  that  the  binding  for  x  is  not  garbage.  This  implies  the  existence  of  a 
heap  value  h  and  variable  2:  such  that 

P'  i-^*letrec  P['  1+)  {xi  =  1,  X2  =  2,  x  =  (xi,  X2),  z  =  h}  \n  (Aj/.tti  x)  2 

Otherwise,  x  would  never  be  involved  in  a  reduction  step.  Given  this  finite  reduction  sequence  for 
P',  it  follows  that  P  letrec  if'  1+)  {2  =  h}  in  2  In  short,  the  evaluation  of  P  terminates  with  an 
answer  given  the  assumption  that  x  is  not  garbage. 

Since  the  two  cases  show  that  GC  claims  x  is  not  garbage  if  and  only  if  P  terminates  with  an 
answer,  we  have  established  the  proposition.  □ 


4  Reachability-Based  Garbage  Collection 

Since  computing  an  optimal  collection  is  undecidable,  a  garbage  collection  algorithm  must  conser¬ 
vatively  approximate  the  set  of  garbage  bindings.  Most  garbage  collectors  compute  the  reachable 
set  of  bindings  in  a  program,  given  the  variables  in  use  in  the  current  instruction  expression  and 
control  state.  All  reachable  bindings  are  preserved;  the  others  are  eliminated. 
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In  Section  4.1  we  present  a  general  specification  for  reachability-based  garbage  collection  and 
prove  that  it  only  collects  true  garbage.  In  Section  4.2  we  give  a  high-level  description  of  an 
algorithm  based  on  tracing  collection  and  prove  that  the  algorithm  satisfies  our  specification.  In 
Section  4.-3  we  specialize  our  algorithm  to  one  that  takes  advantage  of  a  generational  partition  and 
in  Section  4.4,  we  show  how  generational  collection  works  in  the  presence  of  assignment. 

4.1  The  Free- Variable  Rule 

Following  Felleisen  and  Hieb  [11],  reachability  in  Age  is  formalized  by  considering  free  variables. 
The  following  “free-variable”  GC  rule  describes  bindings  as  garbage  if  there  are  no  references  to 
these  bindings  in  the  other  bindings,  nor  in  the  currently  evaluating  expression: 

(fv)  letrec  Hi  i±)  H2  in  e  1-^  letrec  Hi  in  e  {Dom{H2)  n  FF(letrec  Hi  in  e)  =  0) 

The  fv  rule  is  correct  in  that  it  only  removes  garbage,  and  thus  computes  valid  collections.  The  keys 
to  the  proof  of  correctness  of  fv  are  a  postponement  lemma  and  a  diamond  lemma.  The  statements 
of  these  lemmas  can  be  summarized  by  the  diagrams  of  Figure  4  respectively,  where  solid  arrows 
denote  relations  that  are  assumed  to  exist  and  dashed  arrows  denote  relations  that  can  be  derived 
from  the  assumed  relations. 


Pi 


R 


I 


P2- 


fv 


P2 


R 


fv 


—  —  F3 


Pi 

R 

P' 

^2 


fv 


P2 


R 


fv 


] 


-P3 


Figure  4:  Postponement  and  Diamond  Properties 


Lemma  4.1  (Postponement)  If  Pi  i-^  F3,  then  there  exists  a  P2  such  that  Pi  1-^ 

P^  ^  P3. 

Proof:  The  proof  proceeds  by  case  analysis  on  the  elements  of  R: 

alloc:  Assume  letrec  Hi'SH2  in  EUi]  letrec  Hi  in  EUi]  1^  letrec  Hi\S{x  =  h]  in  F'Cx].  We 
only  need  to  show  that  fv  applies  after  performing  the  allocation: 

letrec  Hi  l±l  H2  in  EUi]  letrec  FTi  1+)  if2  hJ  {a:  =  h}  in  El.x'] 

But  this  is  clear  since  allocation  only  adds  x  to  the  locations  of  the  resulting  program,  and  x 
cannot  be  in  Dom{H2)  by  the  side-condition  of  the  alloc  rule.  Consequently: 

letrec  Hi\±)  H2^  {x  =  h]  in  £'[x]  letrec  ifi  1+)  {x  =  h}  in  £^[x] 
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proj:  Assume  letrec  Hi  l+l  H2  in  x]  letrec  Hi  in  Eliii  xl  1-^  letrec  Hi  in  Elxi]  Since 

proj  applies,  x  must  be  bound  to  some  pair  {xi,X2)  and  furthermore,  x  must  be  in  Hi  else 
fv  does  not  apply.  Thus  we  may  swap  the  steps: 

letrec  Hi  l+j  H2  in  E[.ni  a;]  1-^  letrec  Hi  1+1  H2  in  El.xi]  letrec  Hi  in 

app:  Assume  letrec  Hi  1+)  H2  in  Elx  y]  letrec  Hi  in  Eix  y]  letrec  Hi\S  {z  —  h}  in  Elel 
Since  app  applies,  x  must  be  bound  to  Az.e,  y  must  be  bound  to  /i,  and  z  cannot  occur  in  the 
domain  of  Hi.  Furthermore,  both  x  and  y  must  be  bound  in  Hi.  Performing  the  application 
first  yields: 


letrec  Hi  i+l  H2  in  E[.x  y]  letrec  i?i  1+)  W  =  h}  in  E{.e] 

The  resulting  program  is  well  formed  only  if  2  is  not  already  bound  in  H2.  This  can  be 
ensured  by  a-converting  the  program  if  necessary.  Let  x'  be  a  variable  that  occurs  in  e.  Then 
either  x'  is  z  or  x'  occurs  free  in  Xz.e.  In  either  case,  x'  is  necessarily  bound  in  iLi  l+l  {z  =  h} 
in  order  for  the  fv  rule  to  apply,  thus  x'  is  not  bound  in  H2.  Consequently,  we  can  take  the 
following  step: 

letrec  Hi  kti  H2^  {z  =  h}  in  £’[e]  1-^  letrec  Hi  1+)  {z  =  h}  in  H[e] 


□ 


Lemma  4.2  (Diamond)  If  Pi  P2  and  Pi  1-^  then  there  exists  a  F3  such  that  P2  1-^  P3 
and  P2  P3. 

Proof:  Assume  Pi  =  letrec  Hi  i+i  H2  in  P[/],  P2  =  letrec  Hi  in  EUl ,  and  Pi  P2.  We  can 

easily  show  by  case  analysis  on  the  elements  of  R  that  if  Pi  p^  where  P2  =  letrec  Hi  l+l  H2  W 
H3  in  PCe] ,  for  some  H3  and  e,  then  P2  P3  and  P2  P3  where  P3  =  letrec  Hi  I+1H3  in  HCe] . 

□ 

With  the  Postponement  and  Diamond  Lemmas  in  hand,  it  is  straightforward  to  show  that  fv 
is  a  correct  GC  rule. 

Theorem  4.3  (Correctness  of  fv)  If  P  1-^  P' ,  then  P'  is  a  collection  of  P. 

Proof:  Let  P  =  letrec  Hi  l+l  H2  in  e  and  P'  =  letrec  Hi  in  e  such  that  P  1-^  P'.  We  must  show 

P  evaluates  to  an  integer  value  iff  P'  evaluates  to  the  same  integer.  Suppose  P'  JJ./j  letrec  H  in  a; 
and  H{x)  =  i.  By  induction  on  the  number  of  rewriting  steps  using  the  Postponement  Lemma, 
we  can  show  that  P  (l/j  letrec  H  l±l  H2  in  x  and  clearly  (H  l+l  H2)(a:)  =  H{x)  =  i.  Now  suppose 
P  letrec  Hina;  and  H  (a;)  =  i.  By  induction  on  the  number  of  rewriting  steps  using  the  Diamond 
Lemma,  we  know  that  there  exists  an  H'  such  that  P'  letrec  H'  in  x  and  letrec  H  in  a; 
letrec  H'  in  x.  Thus,  x  must  be  bound  in  H'  and  since  fv  only  drops  bindings,  H'{x)  =  i.  □ 

This  theorem  shows  that  a  single  application  of  fv  results  in  a  Kleene  equivalent  program.  A 
real  implementation  interleaves  garbage  collection  with  evaluation.  The  following  theorem  shows 
that  adding  fv  to  R  preserves  evaluation. 

Theorem  4.4  For  all  programs  P,  (P,  P)  ~  (P,  H  +  fv). 
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Proof:  Clearly  any  evaluation  under  R  can  be  simulated  by  i?  +  fv  simply  by  not  performing  any 
fv  steps.  Thus,  if  P  JJ-/?  A  then  P  -U-^+fv  A.  Now  suppose  P  -Hn+fv  letrec  Hi  in  Xi  and  ^1(2:1)  =  i. 
Then  there  exists  a  finite  rewriting  sequence  using  i?  +  fv  as  follows; 

T~)  R.^fv  7—)  R-f-fv  T-k  R+fV  R^fv  I  ,  yt  * 

P  Pi  P2  I — )■  •  •  ■  I — >  letrec  Hi  m  Xi 


We  can  show  by  induction  on  the  number  of  rewriting  steps  in  this  sequence,  using  the  Postponement 
Lemma,  that  all  fv  steps  can  be  performed  at  the  end  of  the  evaluation  sequence.  This  provides  us 
with  an  alternative  evaluation  sequence  where  all  the  R  steps  are  performed  at  the  beginning: 


P 


P{ 


Po 


PL 


n+l 


P 


n+2 


letrec  Hi  \n  Xi 


Since  fv  does  not  affect  the  expression  part  of  a  program  and  only  removes  bindings  from  the 
heap,  PL  =  letrec  Hi  IS  H2  \n  x  for  some  H2-  Thus,  P  JJ-;?  letrec  Hi  l+l  H2  in  x.  Since  Hi{x)  =  i, 
{Hi^±)H2){x)  =  i.  □ 


4.2  The  Free- Variable  Tracing  Algorithm 

The  free- variable  GC  rule  is  a  specification  of  a  garbage  collection  algorithm.  It  assumes  some 
mechanism  for  partitioning  the  set  of  bindings  into  two  disjoint  pieces  such  that  one  set  of  bindings 
is  unreachable  from  the  second  set  of  bindings  and  the  body  of  the  program.  Real  garbage  collec¬ 
tion  algorithms  need  a  deterministic  mechanism  for  generating  this  partitioning.  It  is  possible  to 
formulate  an  abstract  version  of  such  a  mechanism,  the  free-variable  tracing  algorithm,  by  lifting 
the  ideas  of  mark-sweep  and  copying  collectors  to  the  level  of  program  syntax. 

We  adopt  the  terminology  of  copying  collection  in  the  description  of  the  free-variable  tracing 
algorithm.  We  use  two  heaps  and  a  set:  a  “from-heap”  (P/),  a  “scan-set”  (5),  and  a  “to-heap” 
{Ht).  The  from-heap  is  the  set  of  bindings  in  the  current  program  and  the  to-heap  will  become 
the  set  of  bindings  preserved  by  the  algorithm.  The  scan-set  records  the  set  of  variables  reachable 
from  the  to-heap  that  have  not  yet  been  moved  from  the  from-heap  to  the  to-heap.  The  scan-set 
is  often  referred  to  as  the  “frontier.” 

The  body  of  the  algorithm  proceeds  as  follows:  A  variable  x  is  removed  from  5  such  that  Hj 
has  a  binding  for  x.  If  no  such  locations  are  in  5,  the  algorithm  terminates.  Otherwise,  it  scans  the 
heap  value  h  to  which  x  is  bound  in  the  from-set  P/,  looking  for  free  variables.  For  each  y  6  FV{h), 
it  checks  to  see  if  y  has  already  been  forwarded  to  the  to-set  Ht-  Only  if  y  is  not  bound  in  Ht  does 
it  add  the  variable  to  the  scan-set  5.  This  ensures  that  a  variable  moves  at  most  once  from  the 
from-heap  to  the  scan-set. 

Formulating  the  free-variable  tracing  algorithm  as  a  rewriting  system  is  easy.  It  requires  only 
one  rule  that  relates  triples  of  from-sets,  scan-sets,  and  to-sets: 

(P/ l±l  {x  =  h},5i±i  {a;},Pi)  =>  {Hf,Sl}{FV{h)\{Dom{Ht)^{x})),Ht^{x  =  h}) 

Initially  the  free  variables  of  the  evaluation  context  and  instruction  expression,  which  correspond 
to  the  “roots”  of  a  computation,  are  placed  in  5.  Computing  the  free  variables  of  the  context 
represents  the  scanning  of  the  “stack”  of  a  conventional  implementation  while  computing  the  free 
variables  of  the  instruction  expression  corresponds  to  scanning  the  “registers.”  The  initial  tuple  is 
re-written  until  we  reach  a  state  where  no  variable  in  the  scan-set  is  bound  in  the  from-heap.  At  this 
point,  we  have  forwarded  enough  bindings  to  the  to-heap.  This  leads  to  the  following  free- variable 
tracing  algorithm  rule: 

letrec  P  in  e  letrec  H'  in  e 
(fva)  if 

(P,  FF(e),  0)  (P",  5,  P')  and  Dom[H'')  n  5  =  0 


9 


Clearly,  the  algorithm  always  terminates  since  the  size  of  the  from-heap  strictly  decreases  with  each 
step.  Furthermore,  this  new  rewriting  rule  is  a  subset  of  the  rule  fv,  which  implies  the  correctness 
of  the  algorithm. 

Theorem  4.5  If  P  P' ,  then  P  P'. 

Proof:  Let  P  =  letrec  Lf  in  e  be  a  Age  program.  The  first  step  is  to  prove  the  basic  invariants  of 
the  garbage  collection  rewriting  system.  If  {H,  FV{e),$)  =>*  {Hf,S,Ht),  then  Hf  \S  Ht  =  H  and 
FF(letrec  Hf  in  e)  =  S.  Now  let  P'  =  letrec  Hi  in  e  and  suppose  P  P'.  Then, 

{Hi  IS  H2,  FV(e),%)  =>*  {H2,  S,  Hi). 

and  Dom{H2)  n  5  =  0.  By  the  invariants,  FF(letrec  Hi  in  e)  =  S,  so  Dom{H2)  n  FV{P')  =  0. 
Consequently,  P  P'  .  □ 

If  we  require  that  a  collection  algorithm  produce  a  closed  program,  then  fva  is  an  optimal 
collection  algorithm.  That  is,  if  P  is  a  closed  program  and  P  P',  then  P'  has  the  fewest 
bindings  needed  to  keep  the  program  closed  without  affecting  evaluation.  Assuming  each  step  in 
the  free-variable  tracing  algorithm  takes  time  proportional  to  the  size  (in  symbols)  of  the  heap 
object  forwarded  to  the  to-heap,  the  time  cost  of  the  algorithm  is  proportional  to  the  amount  of 
data  preserved,  not  the  total  amount  of  data  in  the  original  heap. 

4.3  Generational  Garbage  Collection 

The  free- variable  tracing  algorithm  examines  all  of  the  reachable  bindings  in  the  heap  to  determine 
that  a  set  of  bindings  may  be  removed.  By  carefully  partitioning  the  heap  into  smaller  heaps,  a 
garbage  collector  can  scan  less  than  the  whole  heap  and  still  free  significant  amounts  of  memory. 
A  generational  partition  of  a  program’s  heap  is  a  sequence  of  sub-heaps  ordered  in  such  a  way  that 
“older”  generations  never  have  pointers  to  “younger”  generations. 

Definition  4.6  (Generational  Partition)  A  generational  partition  of  a  heap  H  is  a  sequence 
of  heaps  Hi,  H2, . .  • ,  Hn  such  that  H  =  Hi  S  H2  l+l  •  •  •  l+)  Hn  and  for  all  i  such  that  1  <  i  <  n, 
FV{Hi)  n  Dom{Hi+i  l±)  iLtq.2  l±)  •  ■  •  W  Hn)  =  0-  The  Hi  are  referred  to  as  generations  and  Hi  is  said 
to  be  an  older  generation  than  Hj  if  i  <  j. 

Given  a  generational  partition  of  a  program’s  heap,  a  free-variable  based  garbage  collector  can 
eliminate  a  set  of  bindings  in  younger  generations  without  looking  at  any  older  generations. 

Theorem  4.7  (Generational  Collection)  Let  Hi,...,  Hi, . .  .,Hn  be  a  generational  partition  of 
the  heap  of  P  =  letrec  H  in  e.  Suppose  Hi  —  {Hi  1+)  Hf),  and  Dom{Hf)  n  Fy(letrec  H}  1+)  Hi+i  1+) 

■  •  •  l±)  in  e)  =  0.  Then  P  letrec  {H  \  Hf)  in  e. 

Proof:  We  must  show  that  Dom{Hf)  fl  FF(letrec  {H  \  Hf)  in  e)  =  0.  Since  Hi,-  -  -  .Hn  is  a 

generational  partition  of  H,  for  all  j,  1  <  j  <  i,  FV{Hj)  n  Dom{Hj.i.i  l±)  •  •  •  1+)  Hn)  =  0.  Hence, 
FV{Hi  W  ■  •  ■  W  F,_i)  n  Dom{Hf)  =  0.  Now, 

FF(letrec  H  \  Hf  in  e)  n  Dom{Hf) 

=  {FV{H\Hf)U  FV{e))nDoTn{Hf) 

=  {FV{Hi  S---S  H^-i)  U  FV{Hl  S---SHn)U  FV{e))  n  Dom{Hf) 

=  {FV{Hi  S---S  Hi^i)  n  DomiHf))  U  {{FV{Hf  S---SHn)U  FV{e))  n  Dom{Hf)) 

=  0  U  {{FV{H}  S---SHn)S  FV{e))  n  Dom{Hf)) 

=  FF(letrec  Hf  S  -  - -S  Hn  m  e)  Dom{Hf) 

=  0 
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□ 

Generational  collection  is  important  for  three  practical  reasons:  First,  evaluation  of  closed,  pure 
Age  programs  makes  it  easy  to  maintain  generational  partitions. 

Theorem  4.8  (Generational  Preservation  for  R)  Let  P  —  letrec  H  \n  e  be  a  closed  program. 

is  a  generational  partition  of  H  and  P  letrec  H  \±S  H'  in  e,  then  Hi, . . Hn,  H' 
is  a  generational  partition  of  H  ^  H' . 

Proof:  The  proj  rule  does  not  modify  the  heap,  so  it  clearly  preserves  the  generational  partition. 
If  the  alloc  rule  is  applied,  then  e  =  E[K]  for  some  E  and  h  and  H'  =  {x  =  h}.  Since  P  is  closed, 
X  cannot  occur  free  in  H .  Thus  for  all  i,l  <  i  <  n,  FV{Hi)  H  Dom{Hij^i'SHij^2  W  •  •  •  WFfO  — 

If  the  app  rule  is  applied,  then  e  —  E[.x  y]  for  some  E,  x,  and  y  such  that  x  is  bound  to  Xz.e'  and 
y  is  bound  to  some  h  in  H.  Thus,  H'  =  {z  —  h}  and  since  P  is  closed,  2:  cannot  occur  free  in  H . 
Thus  for  all  i,  1  <  i  <  n,  FV{Hi)  fl  Dom(Hi+i  l+J  Hijf.2  l±l  •  •  •  W  W  H')  =  0-  O 

The  second  reason  generational  collection  is  important  is  that,  given  a  generational  partition, 
wre  can  directly  use  the  free-variable  tracing  algorithm  to  generate  a  collection  of  a  program.  The 
following  rule  invokes  the  free- variable  algorithm  on  the  program  letrec  H2  in  e  where  Hi,H2  is 
a  generational  partition  of  the  original  program’s  heap.  The  resulting  heap  is  glued  onto  Hi  to 
produce  a  collection  of  the  program. 

letrec  H  in  e  1-^  letrec  Hi  ^  Hl^  in  e 
(gen)  if  letrec  H2  in  e  letrec  H2  in  e 

and  Hi,H2  form  a  generational  partition  of  H 

The  rule’s  soundness  follows  directly  from  the  Generational  Collection  theorem,  together  with  the 
soundness  of  the  free-variable  tracing  algorithm. 

Theorem  4.9  If  P  ^  P' ,  then  P  ^  P' . 

The  third  reason  generational  collection  is  important  is  that  empirical  evidence  shows  that 
“objects  tend  to  die  young”  [35].  That  is,  recently  allocated  bindings  are  more  likely  to  become 
garbage  in  a  small  number  of  evaluation  steps.  Thus,  if  we  place  recently  allocated  bindings  in 
younger  generations  we  can  concentrate  our  collection  efforts  on  these  generations,  ignoring  older 
generations,  and  still  eliminate  most  of  the  garbage. 

4.4  Assignment  and  Generational  Garbage  Collection 

The  addition  of  certain  language  features  or  implementation  techniques  such  as  assignment  or 
lazy  evaluation  tends  to  break  the  Generational  Preservation  theorem.  For  instance,  consider  the 
addition  of  an  assignment  operator  ( := )  to  Age: 

(expressions)  e  €  Exp  ::=  ■  ■  •  \  Ci  :=  62 

(contexts)  E  €  Ctxt  ::=  •  ■  •  \  E  :=e  \  x  :=  E 

(instructions)  I  €  Instr  ::=  •••  \x:—y 

(set)  letrec  H  ^  {x  =  h,y  =  h'}  in  i?  [x  :=  y]  1-^  letrec  H  ^  {x  —  h' ,  y  =  h'}  in  E  [x] 

resulting  in  a  language  Age-set.  Evaluation  of  Age-set  programs  under  i?-l-  set  does  not  satisfy  the 
Generational  Preservation  theorem.  To  see  this,  consider  the  program: 

letrec  {xq  =  0,  Xi  =  1,  X2  =  (xq,  xq),  X3  =  (x2,  X2)}  in  ttj  (tti  (xi  :=  X3)) 
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where  the  heap  can  be  generationally  partitioned  into  Hi  —  {a;o  =  0,  xi  =  1}  and  H2  =  {x2  = 
{xq,  xq),  xs  =  {x2,  2:2)}.  Performing  the  assignment  results  in  the  program: 


letrec  {2:0  =  0,  2:1  =  (x2,  X2),  2:2  =  (2:0, 2:0),  2:3  =  (x2,  2:2)}  in  tti  (tti  xi) 

but  taking  Hi  =  {2:0  =  0, 2:1  =  (2:2, 2:2)}  and  H2  =  {x2  =  {xq,  xq),  2:3  =  (2:2,  2:2)}  no  longer  yields  a 
generational  partition.  If  we  attempted  to  do  a  generational  collection  on  H2  using  this  partition, 
then  both  X2  and  2:3  would  be  collected  since  there  is  no  reference  to  them  in  the  expression  part 
of  the  program.  This  would  result  in  the  program: 

letrec  {xq  =  0,2:1  =  (2:2,  2:2)}  in  tti  (tti  2:1) 
which  after  one  proj  step  would  be  stuck: 

letrec  {xo  =  0,  xi  =  (x2,X2)}  in  tti  X2 

because  X2  is  unbound.  Yet,  if  no  collection  was  performed,  the  computation  would  not  get  stuck 
and  would  return  an  answer  of  0. 

It  is  possible  to  maintain  a  generational  partition  for  Age-set  during  evaluation.  We  simply  keep 
track  of  all  “older”  bindings  that  are  updated  and  move  them  from  the  older  generation  to  a  younger 
generation.  The  following  theorem  formalizes  this  idea  for  two  generations.  The  generalization  to 
multiple  generations  is  straightforward. 

Theorem  4.10  (Generational  Preservation  for  R  +  set)  If  P  =  letrec  Hi\+}H2  in  e  is  a  closed 
Age-set  program  and  P  where  P'  =  letrec  Hi  l±i  W  Hz  in  e'  and  Dom[H2)  =  Dom{H2), 

then  Hi,  {H2  W  H3)  is  a  generational  partition  of  P' . 

The  theorem  states  that  if  we  evaluate  P  for  some  number  of  steps  resulting  in  P' ,  where  H1WH2 
is  conceptually  the  older  generation,  H2  is  the  subset  of  the  older  generation  that  is  modified  via 
set  to  become  H2,  and  Hz  is  the  younger  generation  of  newly  allocated  bindings,  then  Hi  and 
(H2  l±i  Hz)  form  a  generational  partition.  There  are  a  variety  of  techniques  for  determining  which 
values  in  the  older  generation  must  be  moved  to  the  younger  generation.  We  refer  the  interested 
reader  to  Hosking  et  al.  [19]. 

5  Garbage  Collection  via  Type  Recovery 

The  delimiters  and  other  tokens  of  the  abstract  syntax  mark  or  “tag”  heap  values  with  enough 
information  that  we  can  distinguish  pairs  from  functions,  pointers  from  integers,  etc..  This  allows 
us  to  navigate  through  the  memory  unambiguously,  but  placing  tags  on  heap  values  and  stripping 
them  off  to  perform  a  computation  can  impose  a  heavy  overhead  on  the  running  time  and  space 
requirements  of  programs  [33].  An  alternative  to  tagging  is  the  use  of  types  to  determine  the  shape 
of  an  object.  If  types  are  determined  at  compile  time  and  evaluation  maintains  enough  information 
that  the  types  of  reachable  objects  can  always  be  recovered,  then  there  is  no  need  to  tag  values. 

A  number  of  researchers  have  made  attempts  to  explore  this  alternative  [7,  8,  3,  15,  26,  34,  2], 
but  none  of  them  presented  concise  characterizations  of  the  underlying  techniques  with  correctness 
proofs.  In  this  section,  we  present  the  basic  idea  behind  type-recovery  based  garbage  collection.  In 
the  following  subsection,  we  give  a  simple  overview  of  the  techniques  used  to  record  and  reconstruct 
the  types  of  objects  in  collectors  such  as  Britton’s  [8]  and  Tolmach’s  [34].  We  then  introduce 
Age-mono,  an  explicitly  typed,  monomorphic  variant  of  Age.  We  show  how  to  adapt  the  free- 
variable  tracing  algorithm  to  recover  types  of  objects  in  the  heap  and  to  use  these  types  in  the 
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traversal  of  heap  objects  instead  of  abstract  syntax.  The  proof  of  correctness  for  this  garbage 
collection  algorithm  is  given  by  extending  the  proof  of  soundness  of  the  type  system  for  Age-mono. 
The  last  subsection  extends  the  work  to  an  explicitly  typed,  polymorphic  language. 

5.1  An  Overview  of  Type  Recovery 

The  type  of  a  data  structure  such  as  a  tuple  or  integer  determines  the  types  of  the  components 
of  the  data  structure  (if  any),  but  the  type  of  a  function  does  not  contain  the  types  of  the  free 
variables  of  the  function.  If  the  compiler  associates  the  types  of  all  free  variables  with  the  code 
of  a  function,  it  becomes  possible  to  recover  the  types  of  all  reachable  objects  in  the  heap,  given 
the  set  of  reachable  objects  from  the  current  evaluation  context  and  instruction.  This  provides  a 
potential  for  space  savings  compared  to  tagging  all  values,  because  type  information,  like  code,  can 
be  shared  among  diflPerent  applications  of  the  same  function. 

For  example,  in  a  low-level  model  that  uses  closures  (an  explicit  environment  mapping  variables 
to  values  paired  with  an  expression)  instead  of  substitution,  the  expression  part  or  “code”  of  the 
closure  can  be  shared.  The  type  information  needed  to  find  and  preserve  the  free  variables  of  the 
closure  is  simply  a  type  environment  that  lists  the  types  of  each  value  in  the  closure’s  environment. 
This  information  can  also  be  shared  because  the  types  of  the  free  variables  are  the  same  for  each 
value  environment  paired  with  a  given  expression. 

As  noted  earlier,  determining  the  free  variables  of  the  evaluation  context  and  instruction  cor¬ 
responds  to  scanning  a  stack  and  registers  in  a  conventional  implementation.  Thus,  the  compiler 
must  provide  a  type  map  for  each  stack  frame.  Like  the  type  environment  associated  with  a  closure, 
this  information  can  be  recorded  at  compile  time  and  a  pointer  to  the  information  can  be  pushed 
on  the  stack  as  a  new  stack  frame  is  allocated.  The  type  information  is  “collected”  as  stack  frames 
are  popped. 

In  our  high-level  framework,  we  use  a  global  heap  instead  of  closures,  rely  upon  ct-conversion  to 
generate  unique  names,  and  use  evaluation  contexts  instead  of  an  explicit  stack  to  model  evaluation. 
Consequently,  the  set  of  free  variables  changes  as  expressions  are  evaluated  and  a-conversion  is 
performed.  Thus,  the  type  maps  associated  with  functions  and  evaluation  contexts  must  also 
change.  Our  approach  is  to  represent  these  type  maps  implicitly  by  initially  tagging  each  expression 
with  its  type  and  by  allowing  the  substitution  that  occurs  as  part  of  a-conversion  to  replace  a 
variable  with  a  variable,  but  leave  the  type  tag  intact.  The  type  map  information  associated  with  a 
closure  or  evaluation  context  can  then  be  extracted  by  a  simple  function  similar  to  the  FV  function 
of  Figure  2.  As  data  structures  are  allocated,  the  type  information  is  stripped,  leaving  the  heap 
essentially  tag  free  and  ensuring  that  we  do  not  use  the  abstract  syntax  to  navigate  the  heap. 
However,  the  type  information  remains  intact  within  functions,  corresponding  to  the  explicit  type 
maps  needed  for  closures. 

5.2  Age-mono 

Age-mono  is  an  explicitly  typed,  monomorphic  variant  of  Age.  The  set  of  types  (r)  of  Age-mono 
contains  the  conventional  basic  types  and  constructed  types  for  typing  a  functional  programming 
language  like  Age.  The  expressions  of  Age-mono  are  the  same  as  for  Age,  except  that  each  raw 
expression  (n)  is  paired  with  some  type  information  (see  Figure  5).  Heap  values  are  not  paired 
with  their  type,  reflecting  the  fact  that  the  memory  is  “almost  tag  free.” 

The  evaluation  contexts  {E)  consist  of  a  raw  context  (17)  and  a  type  (r).  Raw  contexts  are 
filled  with  instructions  (7)  which  are  a  subset  of  the  raw  expressions  (u).  The  evaluation  rules  for 
Age-mono,  named  RM,  are  variants  of  the  rules  for  Age  that  largely  ignore  the  type  information 


13 


Types: 

(types) 

T 

G  Type  : 

=  int  1  "1  X  r2  1  rj  — )•  r2 

Programs: 

(expressions)  e 

6 

TExp  ::= 

(u  :  r) 

u 

6 

UExp  ::= 

X  1  z  1  (61,62)  \  TTi  e  \  Xx:T.e  \  ei  62 

(heap  values)  h 

G 

Hval  ::= 

i  1  (xi,  X2)  1  XxiT.e 

(heaps)  H 

e 

Heap  ::= 

(xi  —  /zi, , . . ,  Xfi  — 

(programs)  P 

G 

Prog  ::= 

letrec  H  \n  e 

(answers)  A 

G 

Arts  ::= 

letrec  H  \n  {x  :  t) 

Evaluation  Contexts  and  Instructions: 

(contexts)  E  G  TCtxt  : 

{U-.r) 

U  e  UCtxt  : 

[]  1  {E,e)  1 

{{x:t),E)  \  -Ki  E  \  E  e  \  (x:r)  E 

(instructions)  I  G  Instr  : 

i  1  ((a;i:'ri),( 

X2'-T2))  1  Xx-.T.e  I  TTi  (x:7-)  1  TTo  (x:r) 

(a;:ri)  (yrra) 


Figure  5:  The  Syntax  of  Age-mono 


on  the  sub-expressions  of  the  program’s  body. 


(alloc-int) 

(alloc-pair) 

(alloc-fn) 

(proj) 

(app) 


letrec  H  in  EUl  letrec  i?  l+l  {x  =  i}  in  E[x] 

letrec  ff  in  E[(xi:ti,  X2:t2}J  letrec  1+)  {x  =  (xi,X2)}  in  £'[x] 

letrec  H  in  ElXy.T.el  letrec  H  ^  {x  —  Xy.r.e}  in  £'[x] 

letrec  H  in  ECff;  (x:r)]  letrec  H  in  Elxi"]  iH{x)  —  {xx,X2),i  =  1,2) 

letrec  H  in  £^[(x:ri)  {y.T2)l  letrec  if  l+l  {z  =  H{y)}  in  Eiul  {H{x)  =  Xz\t' .{u:r")) 


Allocation  of  integers,  tuples  and  functions  strips  the  type  tag  off  of  the  heap  value  before  placing 
it  in  the  heap.  Allocation  of  tuples  also  removes  the  tags  from  the  components  of  the  tuple.  The 
removal  of  type  information  corresponds  to  the  passage  of  a  value  from  code  to  data  and  does  not 
necessarily  reflect  a  runtime  cost.  Projection  and  application  are  essentially  the  same  as  for  Age. 
Note  that  substitution  of  a  result  expression  for  an  instruction  occurs  “in  place,”  and  hence  the 
type  of  the  instruction  is  ascribed  to  the  expression. 

The  notion  of  a  stuck  state  is  adapted  in  accordance  with  the  type  structure  of  the  language. 


Definition  5.1  (Age- mono  Stuck  Programs)  A  program  is  stuck  if  it  is  of  one  of  the  following 
forms: 

•  letrec  H  in  Elxi  (x:r)]  {x  ^  Dom{H)  or  H{x)  ^ 

•  letrec  H  in  £^[(x:ri)  (y:r2)]  {x  ^  Dom{H)  or  H{x)  ^  Xz:T.e  or  y  ^  Dom[H)). 


5.3  Static  Semantics 

The  static  semantics  of  Age-mono  consists  of  four  judgements  about  program  components.  The  first 
judgement,  F  >  e,  is  a  binary  relation  between  a  type  assignment  F,  mapping  a  finite  set  of  variables 
to  types,  and  a  typed  expression  e.  Figure  6  (Expressions)  contains  the  fairly  conventional  inference 
rules  for  expressions  that  generate  the  static  semantics.  Typing  heaps  and  complete  programs 
requires  three  additional  judgements.  The  first  is  F  >  h  :  r  which  asserts  that  the  heap  value  h 
has  type  r  under  the  assumptions  in  F.  The  second  is  F  c-  i?  :  F',  which  asserts  that  the  variables 
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Expressions: 


var 


(pairj 


(& 


r  l±)  {x:t^  >  (x  :  r) 

ri>(Mi:ri)  r  >  (^2:7-2) 

r  >  (((u2:ri),  {uo-T^))  :  n  x  T2) 

T  l+J  {x:ri}  >  (u  :  r2) 


(int) 
(proj) 


r  >  (2  :  int) 
r  >  (u  :  ri  X  To) 


r  >  (Ax:ri.(w:r2)  :  n  -4-  r2) 
Heaps  and  Programs: 

(h-int) 

.  ,  r  >  (xi:ri)  r  >  (x2:t2) 

(h-pairj 


(app) 


r  >  (TTj  (u  :  ri  X  To)  :  n) 

T  >  {ui  :  Ti  T2)  r  >  (w2:’'i) 

r>  ((ui  :  Ti  r2)  {u2:ti)  :  T2) 


(2=1,2) 


r  >  2  :  int 


(heap) 


r  >  (xi,x2) :  n  X  72 
Vx  €  Dom{T') .  F  l±J  T'  i>  H{x)  :  r'(x) 

r  i>  iJ  :  r' 


(h-fn) 


r  >  (Ax:ri.e  :  ti  — >•  r2) 
r  >  Ax:ri.e  :  ri  — >■  T2) 

:  r  r>e 

(prog)  - — - — - 

>  letrec  nine 


Figure  6:  The  Static  Semantics  of  Age-mono 


given  type  r  in  T'  are  bound  to  heap  values  in  H  of  the  appropriate  type,  under  the  assumptions 
in  r.  The  judgement’s  definition  via  the  heap  rule,  similar  to  Harper’s  store  typing  [18]  and  the 
typing  for  Wright  k  Felleisen’s  Reference  ML  [37],  requires  “guessing”  the  types  of  the  values  in 
the  heap  and  verifying  these  guesses  simultaneously  due  to  potential  cycles.  The  third  judgement, 

>  P,  asserts  the  well-typing  of  a  complete  program.  Figure  6  (Heaps  and  Programs)  contains  the 
necessary  inference  rules  for  all  of  these  judgements. 

Definition  5.2  (Well  Formed  Age-mono  Programs)  A  Xgc-mono  program  P  is  well  formed  if 

>  P  is  derivable. 

The  calculus  Age-mono  is  type  sound  in  that  evaluation  of  well  formed  programs  cannot  get 
stuck  [37].  Our  proof  of  soundness  uses  a  subject-reduction  based  argument  in  the  style  of  Wright 
and  Felleisen  [37]. 

Theorem  5.3  (Type  Soundness)  If  >  P  then  either  P  is  an  answer  or  else  there  exists  some 
P'  such  that  P  P'  and  >  P' . 

Proof  (sketch):  The  first  two  lemmas  (below)  are  needed  to  prove  properties  about  the  allocation 
rule.  The  Weakening  lemma  allows  us  to  throw  extra  information  into  a  type  assignment  and  still 
type  check  an  expression;  the  Allocation  lemma  allows  us  to  replace  an  expression  with  a  variable, 
as  long  as  that  location  is  placed  in  the  type  assignment  with  the  proper  type. 

Lemma  5.4  (Weakening)  IfT>e  and  x  ^  FV{e),  then  F  l±)  {x:r}  >  e. 

Lemma  5.5  (Allocation)  If  T  i>  {u  :  t)  and  T  >  FM  and  x  ^  DomfT),  then  T  l+J  {x:r]  t> 
F[(x:t)]. 

The  Unique  Decomposition  lemma  allows  us  to  deconstruct  a  program  into  a  unique  evaluation 
context  and  instruction  expression. 
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Lemma  5.6  (Unique  Decomposition)  If  P  =  letrec  H  \n  e  has  no  free  variables,  then  either  P 
is  stuck,  P  is  an  answer,  or  else  there  exists  unique  E  and  I  such  that  e  =  E  [/] . 

Lemma  5.7  (Stuck  Programs  Untypeable)  If  P  is  a  stuck  program,  then  f  P. 

Finally,  the  key  lemma  is  Type  Preservation,  which  asserts  that  if  a  program  is  well  typed  and  it 
takes  a  step,  then  the  resulting  program  is  also  well  typed. 

Lemma  5.8  (Type  Preservation)  If  >  P  and  P  P’ ,  then  >  P' . 

Proof  (sketch):  Follows  from  the  Unique  Decomposition,  Weakening,  and  Allocation  lemmas, 
together  with  an  examination  of  each  of  the  rules  of  RM.  □ 

Given  these  lemmas,  the  proof  of  type  soundness  is  straightforward.  Suppose  >  P  and  P  does  not 
diverge.  Then  there  exists  some  P'  such  that  P  E^*P'  and  P'  is  canonical  with  respect  to  RM. 
Further  suppose  that  P'  —  letrec  H  \n  e  for  some  H  and  e.  If  e  =  then  by  Type  Preservation, 

[>  letrec  H  in  x:t  and  the  theorem  is  satisfied.  Otherwise,  by  the  Unique  Decomposition  lemma, 
P'  must  be  stuck  and  thus  [>  P'  is  not  derivable,  contradicting  type  preservation.  □ 

5.4  Using  Types  in  Garbage  Collection 

Specifying  a  valid  garbage  collection  rule  that  exploits  types  is  now  straightforward.  The  key 
property  that  the  rule  must  preserve  is  type  preservation.  That  is,  if  P  P' ,  and  P  is  well  typed, 
then  P'  must  be  well  typed.  One  way  to  achieve  this  goal  is  to  make  it  into  a  side-condition  of  the 
GC  rule: 

(mono)  letrec  Hi  ^  H2  \n  e  letrec  Hi  in  e  if  >  letrec  Hi  in  e 

Theorem  5.9  For  all  well  formed  Xgc-mono  programs  P,  (P,  RM)  ~  (F,  RM  -)-  mono). 

Proof:  Since  mono  preserves  types,  the  type  soundness  proof  trivially  extends  to  the  dynamic 

semantics  with  mono.  This  implies  that,  since  P  is  well  formed,  F  cannot  get  stuck  under  either 
system.  Since  bindings  are  only  dropped  and  not  updated  by  mono,  the  results  of  evaluating  under 
either  system  must  be  the  same.  □ 

Like  the  free-variable  rule  of  Age,  mono  needs  to  be  refined  before  it  can  serve  as  the  basis 
for  an  implementation.  The  refinement  is  similar  to  the  one  from  fv  to  fva  but  uses  the  types 
embedded  in  programs  to  traverse  heap  values.  The  basis  for  the  collection  algorithm  is  a  function 
that  determines  a  minimal,  with  respect  to  set-inclusion,  type  assignment  F  for  any  expression  e 
such  that  r  t>  e: 

MTA{x:t)  —  {a;:r} 

MTAiiir)  =  0 

MTAiiei,  62)  :  n  x  T2)  =  MTA{ei)  U  MTA{e2) 

MTA{Tii  e  :  r)  ==  MTA{e) 

MTA[\x:Ti.e  :  rj  — >•  T2)  =  MTA{e)  \ 

MTA{ei  €2  :  r)  MTA{ei)  U  MTA{e2) 

Lemma  5.10  IfT^e,  then  MTA{e)  l>  e  and  MTA[e)  C  F. 
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If  P  =  letrec  P  in  e  and  P  is  closed,  then  MTA{e)  determines  the  types  of  the  locations  in  the 
heap  H  that  are  immediately  reachable  from  the  expression  e.  A  garbage  collector  can  use  this 
type  information  together  with  the  following  Tag  function  to  traverse  the  reachable  heap  values 
based  on  their  types  instead  of  their  abstract  syntax. 

Tag[\nX\{i)  —  (i:int) 

Tag[ri  x  T2]{{xi,X2))  =  (((a:i:ri),  {x2-.T2))  :  n  X  T2) 

Tag[Ti T':^{\x:Ti.e)  -  [{Xx-.T^.e)  ■.  ti  ^  T2) 

Tag  is  a  curried  function  that  takes  a  type  and  then  takes  a  heap  value  of  that  type,  and  annotates 
that  heap  value  with  enough  information  to  turn  it  back  into  an  expression.  It  is  important  to  note 
that  Tag  pattern-matches  and  operates  according  to  the  type  argument  given  and  not  the  abstract 
syntax  of  the  heap  value  given.  MTA  can  be  used  on  the  resulting  expression  to  find  the  minimal 
type  assignment  for  the  heap  value.  This  provides  us  with  the  free  locations  and  their  types  for 
the  heap  value.  The  following  lemma  summarizes  the  relationship  between  Tag  and  MTA: 

Lemma  5.11  If  ^  >  H  ;  P  1+)  {a::r}  then  there  exists  an  h  such  that 

1.  {x  =  h]CH 

2.  MTA{Tag[T]{h))  >  h  :  T 

3.  MTA{Tag[T]{h))  C  P  W  {x:t} 

Equipped  with  MTA,  we  can  now  redefine  the  free-variable  tracing  algorithm  so  that  it  uses  Tag 
to  traverse  heap  values.  The  algorithm  is  specified  in  the  same  manner  as  fva,  i.e.,  as  a  rewriting 
system  among  tuples  of  the  form  {H /,  P*,  Ht,  P*)  where  Hf  is  the  from-heap,  P^  is  a  type  assignment 
corresponding  to  the  scan-set,  Ht  is  the  to-heap,  and  P(  is  a  type  assignment  for  the  to-heap: 

(iP/  1+1  {a;  =  h},  Pj  lii  {x:t},  Ht,  Pt)  ^  {Hj,  P' ,  Hi'S  {x  =  h},  Pj) 

where  P',  =  (P,  U  MT4(Taff[r](h))  \  P' 

P^  =  Pt  l+l  {a;:r} 

The  algorithm  is  initialized  by  taking  the  program  heap  H  as  the  initial  from-heap  and  the  minimal 
type  assignment  of  the  program  expression  as  P^.  At  each  step  in  the  algorithm,  P^  describes  the 
types  of  all  locations  that  are  immediately  reachable  from  e  or  Ht,  but  have  not  yet  been  forwarded 
to  Hf  Pt  describes  the  types  of  all  locations  that  have  been  forwarded  to  Htf' 

When  a  variable  x  is  found  in  P^  with  type  r  and  x  is  bound  in  Hj  to  the  heap  value  h,  the 
collector  forwards  the  binding  x  =■  h  to  Ht  and  adds  x:t  to  Pt-  It  then  uses  Tag\T]  to  traverse 
h.  placing  the  necessary  type  information  on  the  components  so  that  MTA  can  determine  the 
heap  value’s  minimal  type  assignment.  This  step  provides  the  locations  (and  their  types)  that  are 
immediatelv  reachable  from  h.  Finally,  the  collector  adds  each  of  these  locations  to  P^  unless  they 
have  already  been  forwarded  to  Ht- 

Using  this  algorithm  instead  of  an  a  priori  partitioning  of  the  heaps,  mono-a  becomes  a  high- 
level  specification  of  a  collector  whose  traversal  of  heap  values  uses  types  instead  of  tag  information: 

letrec  Hme  letrec  H'  in  e 
(mono-a)  if 

{H,  MTA{e),<D,  0)  ^*{H",  0,  H',  P) 

The  following  definition  gives  the  primary  invariants  of  the  algorithm: 

^The  garbage  collection  rewriting  system  only  maintcdns  Ft  to  simplify  the  presentation  and  proof;  an  implemen¬ 
tation  will  not  have  to  construct  Ft. 
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Definition  5.12  (mono-a  Invariants)  (if/,  i/j,  Tf)  has  the  mono-a  invariants  with  respect 
to  a  program  letrec  H  \n  e  and  type  assignment  Fq  iff: 

1-  H  =  Hf  1+)  Ht  (each  binding  is  either  in  the  from-heap  or  to-heap.) 

2.  Fj  1+1  Ff  >  e  (every  binding  needed  for  e  is  in  the  scan-set  or  to-heap.) 

3.  Dom[Ts)  C  Dom{H})  (the  scan-set  corresponds  to  bindings  in  the  from-heap.) 

4-  Ts  t>  Ht  :  Fj  (the  scan-set  holds  all  free  variables  in  the  to-heap.) 

5.  F^l+lFiCFo  (the  scan-set  and  to-heap  agree  with  Fq.^ 

Lemma  5.13  Ift!}t>H  :  Fq,  T  has  the  mono-a  invariant  properties  with  respect  to  P  and  Fq,  and 
T  T' ,  then  T'  has  the  mono-a  invariant  properties  with  respect  to  P  and  Fq. 

Proof:  Assume  P  =  letrec  H  \n  e  and  T  =  (Hj  l±)  {a;  =  /i},  F^  l+l  {2;:r},  iFj,  F*)  and  this  rewrites 

to  r  =  [Hj,  F^,  Ht'S{x=^  h},  F;)  where  F^  =  F^  W  {ar:r}  and  F^  =  (F,  U  MTA{Tag[r]{h)))  \  FJ.  We 
must  show: 

1.  H  =  Hf  l+l  1+)  {x  =  h}:  Follows  directly  from  the  first  invariant  for  T. 

2.  F^  1+)  FJ  t>  e:  Follows  directly  from  the  second  invariant  for  T  together  with  weakening. 

3.  Dom{T'^)  C  Dom(Hf):  This  follows  from  the  third  invariant  if  [MTA{Tag[T](h))  \  F^)  C 
Dom{Hf).  This  in  turn  follows  from  t>  H  :  Tq,  {x:t}  C  Fq,  invariant  5  for  T,  and  Lemma 
5.11. 

4.  F'  t>  Ht  \ii  {x  =  h}  :  FJ:  This  follows  from  the  fourth  invariant  of  T  and  the  heap  rule  of  the 
static  semantics  if  we  can  show  (F^  U  {MTA{Ta^T]{h))  \  F^))  i+i  F$  t>  h  :t.  This  in  turn  follows 
from  {a::r}  C  Fq  and  Lemma  5.11. 

5-  r'  l+l  F<  C  Fq:  This  follows  from  the  fifth  invariant  of  T  if  MTA{Tag[T]{h))  C  Fq.  This  in  turn 
follows  from  {x:t}  C  Fq  and  Lemma  5.11. 


□ 

Lemma  5.14  If  $  t>  H  :  Fq,  Fq  t>  e,  and  {H,  MTA{e),$,$)  *2"^  then  T  has  the  mono-a 

invariant  properties  with  respect  to  H  and  Fq. 

Proof:  By  induction  on  the  length  of  the  rewriting  sequence  (FF,  MTA{e),d,  0)  The  base 

case  directly  follows  from  Lemma  5.10.  The  inductive  step  directly  follows  from  Lemma  5.13. 

□ 

The  correctness  of  the  algorithmic  type-based  garbage  collection  rule  can  now  easily  be  verified. 

Theorem  5.15  If  P  is  a  well  formed  program  and  P  pf  then  P  P' . 

Proof:  We  must  verify  that  the  mono-a  garbage  collection  rule  preserves  typability  in  order  for 
mono  to  apply.  That  is,  we  must  show  that  if  P  is  a  well  formed  program,  and  P  TIPff  pf  then 
t>P'. 

Let  P  =  letrec  FF  in  e  and  suppose  >  P.  Then,  for  some  Fq,  0  >  H  :  Fq  and  Fq  >  e.  If 

(FF,  MTAie),^,  0)  0,  FF',  F*), 

then  by  Lemma  5.14  taking  F^  =  0,  we  know  that  0  i>  FF'  :  Ft  (invariant  4)  and  Ft  >  e  (invariant  2) 

.  Thus,  by  the  prog  rule  of  the  static  semantics,  >  letrec  FF'  in  e.  □ 

Furthermore,  the  algorithm  never  gets  stuck,  so  it  always  applies: 
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Theorem  5.16  If  P  is  a  well  formed  program,  then  there  exists  a  program  P'  such  that  P  p' _ 

Proof:  If  the  algorithm  takes  a  step,  the  size  of  the  from-heap  strictly  decreases,  so  we  know  the 

collection  either  terminates  or  gets  stuck.  Here  we  show  that  the  collection  cannot  get  stuck,  so 
it  must  terminate.  Suppose  P  =  letrec  H  \n  e  and  {H,  MTA{e),$,^)  W  {x:t}, 

By  Lemma  5.14,  we  know  that  x  G  Dom{Hf),  since  the  domain  of  the  scan  type-assignment  is 
a  subset  of  the  from-heap.  Consequently,  there  exists  an  h  such  that  H j  =  Hj  hi  {x  =  h}  and 
{HjSshI  {x:T},Ht,Tt)  Hthi  {x  =  h},T'i,)  with  appropriate  and  L'.  □ 

The  mono-a  rule  does  not  perform  type  inference  but  rather  type  recovery.  That  is,  the  types 
of  values  in  the  heap  are  recovered  without  unification.  This  was  accomplished  by  making  the  types 
of  subexpressions  explicit  in  the  program.  We  have  traded  tags  on  data  structures  such  as  pairs, 
with  tags  on  sub-expressions  of  functions.  However,  the  tags  can  be  shared  among  functions  that 
use  the  same  code,  differing  only  in  their  environment.  Furthermore,  some  space  savings  can  be 
realized  for  parametric  data  structures  such  as  lists.  For  example,  if  we  have  x  :  (int  X  int)  list,  as  a 
subexpression,  x  may  be  bound  to  a  large  list,  but  each  of  the  components  of  the  list  have  the  same 
type  and  consequently  share  the  same  “type  tag”  in  an  expression.  A  true  comparison  between 
tag-oriented  and  type-oriented  garbage  collection  will  have  to  be  based  on  implementations. 

5.5  Explicit  Polymorphism 

Extending  type-recovery  based  garbage  collection  to  an  explicitly  polymorphic  language  where  types 
are  passed  to  polymorphic  routines  at  run-time  is  straightforward.  The  language  of  the  extended 
calculus,  Agc-poly,  is  an  adaptation  of  the  Girard-Reynolds  polymorphic  A-calculus.  The  extended 
language  of  types  contains  type  variables  and  quantified  types: 

(type  variables)  t  G  Tvar 

(types)  T  G  Type  •  •  •  |  t  |  Vt.r 

The  marker  V  binds  a  type  variable  t  in  a  type  expression  r.  Types  that  only  differ  in  their  choice 
of  bound  type  variables  are  considered  to  be  equivalent.  FTV{t)  denotes  the  free  type  variables  of 
type  r. 

The  syntactic  categories  for  Agc-poly  are  the  same  as  for  Age-mono,  except  for  the  following 
additions: 

u  G  untyped  expr  ::=  •  •  •  |  Kt.e  \  e  [r] 

h  G  heap  values  ::=  •  ■  •  |  At.e 

The  A-expression,  or  type  abstraction,  is  a  construct  for  introducing  and  scoping  polymorphism; 
type  application  (e  [r])  utilizes  type  abstractions  at  concrete  types. 

The  set  of  evaluation  contexts  for  Agc-poly  is  the  same  as  for  Age-mono,  modulo  the  extended 
syntax.  In  particular,  there  is  no  evaluation  context  within  A-abstractions,  because  type  abstracted 
expressions  are  allocated  heap  values.  The  one-step  rewriting  rules  are  the  same  as  for  Age-mono 
with  the  addition  of  two  new  rules,  one  for  allocating  A-abstractions  and  one  for  governing  the 
application  of  A-abstractions: 

(alloc-t)  letrec  H  in  ElAt-el  letrec  H  h)  {x  =  At.e}  in  Elxl 

(type-app)  letrec  H  in  EL{x:t)  [r']]  letrec  H  in  E\_{t' /t\u1  {H{^)  =  At.{u  :  r”)) 

As  with  other  heap  values,  type  abstracted  expressions  are  allocated  on  the  heap.  Type  application 
{{x:t)  [r'])  replaces  all  free  occurrences  of  the  bound  type  variable  in  a  A-expression  with  a  type. 
A  compiler  for  this  language  might  represent  A-expressions  in  the  same  way  that  it  represents 
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A-abstractions  and  treat  type  application  the  same  as  term  application.  Since  types  are  passed  to 
type  abstractions  during  evaluation,  we  say  that  this  semantics  is  a  type-passing  interpretation.  We 
refer  to  the  extended  set  of  rules  as  RP. 

The  static  semantics  for  Agc-poly  defines  the  following  judgements: 

1.  A  t>  r  (type  T  is  well  formed.) 

2.  A  >  r  (type  assignment  F  is  well  formed.) 

3.  A;  r  >  e  (expression  e  is  well  formed.) 

4.  A;  r  t>  :  r  (heap  value  h  is  well  formed.) 

5.  A;  r  [>  iF  :  F'  (heap  H  is  well  formed.) 

6.  t>  F  (program  P  is  well  formed.) 

where  A  is  a  set  of  type  variables  and  F  is  a  type  assignment.  The  first  judgement  asserts  that  the 
type  T  is  well  formed  with  respect  to  A  in  that  the  free  type  variables  of  r  occur  in  A.  The  second 
judgement  asserts  that  F  is  well  formed  with  respect  to  A,  in  that  all  of  the  types  in  the  range 
of  F  are  well  formed  with  respect  to  A.  The  third  judgement  asserts  that  an  expression  is  well 
formed.  The  judgement  is  defined  in  the  same  fashion  as  the  expression-level  typing  judgement  for 
Age-mono,  except  that  F  is  required  to  be  well  formed  with  respect  to  A,  and  the  resulting  type 
must  also  be  well  formed  with  respect  to  A.  The  following  rules  are  added  for  A-abstractions  and 
type  applications  respectively: 

A>F  A  tt)  {t};  F  t>  (u:r)  A;  F  >  (u  :  Vt.r')  A>r 

A;  F  0  (At.(u:r)  :  Vf.r)  A;  F  >  ((w  :  Vf.r')  [r]  :  {T/t}r') 

Similarly,  a  rule  is  added  to  typecheck  a  A-abstraction  as  a  heap  value: 

AoF  A  l±)  {f};  F  >  (m:t) 

A;  F  [>  Af.(w:r)  :  Vt.r 

The  last  two  judgements  assert  that  heaps  and  programs  are  well  formed  and  are  defined  by  the 
following  inference  rules: 

Va:  e  Fom(F0  .  A;Fl^r  i>  H{x)  :  F^(a;)  0;0[>iF:F  Foe 

A;  F  0  FF  :  F'  o  letrec  FF  in  e 

A  program  is  well  formed  if  the  heap  and  expression  each  type  check  with  an  empty  A.  Conse¬ 
quently,  there  can  be  no  free  type  variables  in  a  well  formed  program. 

As  for  Age-mono,  evaluation  preserves  typing,  so  if  a  program  is  well  formed  and  then  takes 
some  number  of  steps,  the  resulting  program  will  have  no  free  type  variables.  Furthermore,  the 
type  system  for  Agc-poly  is  sound: 

Theorem  5.17  (Type  Soundness)  If  t>  P  then  either  P  is  an  answer  or  else  there  exists  a  P' 
such  that  P  P'  and  t>  P' . 

The  type-based  free-variable  algorithm  can  be  adapted  for  Agc-poly  as  follows.  First,  MT'A  and 
Tag  are  extended  to  work  with  the  new  language  constructs: 

MTA{At.e)  =  MTA{e) 

MTA\e[T])  =  MTA{e) 

Tag\\ft.T]{At.e)  =  (At.e  :  Vt.r) 
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The  garbage  collection  algorithm  itself  remains  unchanged: 

{Hf  kti  {x  =  h},Ts^  {x:T},Ht,rt)  ^  (if/,  T^,  l±)  {a;  =  h},  T^) 

where  T',  =  (T,  U  MTA(Ta5[r](h))  \  T' 

r;  =  r<l±!{a::r} 

To  prove  the  algorithm  does  not  get  stuck,  we  must  show  that  we  never  find  a  variable  in  Fj  that 
is  assigned  an  unknown  type  (i).  But  this  follows  from  the  well-typedness  of  the  original  program. 
Consequently,  it  is  straightforward  to  adapt  the  proofs  of  termination  and  correctness  of  mono-a 
to  show  that  the  rule  poly-a  is  correct  and  always  applies. 

6  Collecting  Reachable  Garbage  Using  Type  Inference 

So  far,  we  have  only  considered  specifications  and  algorithms  for  collecting  unreachable  bindings. 
In  this  section,  we  show  that  by  using  type  inference  during  the  garbage  collection  process,  some 
bindings  that  are  reachable  can  still  be  safely  collected.  That  is,  type  inference  can  be  used  to 
prove  that  an  object  is  garbage  even  though  it  is  reachable. 

As  a  simple  example,  consider  the  following  Age  program: 

letrec  {a;i  =  1,X2  =  2, 0:3  =  (x2,  x^),  X4  =  {xi,X3.)}  in  tti  X4 

Every  binding  in  the  heap  is  accessible  from  the  program’s  expression  (tti  0:4),  so  the  free- variable 
based  collection  rules  can  collect  nothing.  But  clearly  the  program  will  never  dereference  xz  nor 
X2-  The  inference-based  collection  scheme  described  in  this  section  will  allow  us  to  conclude  that 
replacing  the  binding  xz  —  (xziXz)  with  2:3  =  0  (or  any  other  binding)  will  have  no  observable 
effect  on  evaluation.  That  is,  the  inference  collection  scheme  shows  that 

letrec  {xi  =  1,  2:2  =  2,2:3  =  0,2:4  =  (a:i,  X3)}  in  ttj  2:4 

is  Kleene  equivalent  to  the  original  program.  Now  by  applying  the  free- variable  rule,  we  can 
conclude  that  the  binding  2:2  =  2  can  be  safely  collected. 

In  subsection  6.1,  we  introduce  type  inference  for  Age  based  on  the  presentation  of  Mitchell  [25, 
Section  4.5].  In  Section  6.2  we  show  that  if  type  inference  can  assign  a  binding  an  unconstrained 
type  and  the  rest  of  the  program  still  has  a  valid  typing,  then  the  binding  can  effectively  be  collected. 
Our  proof  of  this  theorem  is  based  on  the  method  of  logical  relations,  a  standard  proof  technique 
from  type  theory.  (See  Mitchell  [25,  Section  3]  for  an  overview  of  logical  relations  and  various 
references.) 

6.1  Age  and  Type  Inference 

We  start  by  considering  the  original  Age  language  as  an  implicitly  typed,  monomorphic  language, 
where  the  types  of  the  language  are  the  same  as  for  Age-mono  except  for  the  addition  of  type 
variables: 

(types)  T  6  Type  ::=  t  |  int  |  Ti  X  r2  1  ti  — )■ 

By  implicitly  typed,  we  mean  that  the  terms  of  the  language  are  not  decorated  with  types  as  in 
Age-mono.  We  add  type  variables  to  the  set  of  types  so  that  each  well-formed  expression  has  a 
principal  or  most  general  type  (explained  below'). 

Type  inference  is  the  process  of  decorating  Age  programs  with  types  so  that  the  resulting 
program  type  checks  under  the  Age-mono  rules.  (Refer  to  Figures  1  and  3  for  the  syntax  and 
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dynamic  semantics  of  Age  and  Figure  6  for  the  typing  rules  for  Age-mono.)  Alternatively,  we  may 
directly  specify  a  set  of  typing  rules  for  Age  programs  by  taking  the  typing  rules  for  Age-mono 
and  erasing  the  type  information  from  the  terms,  resulting  in  the  inference  system  of  Figure  7. 
These  rules  define  judgements  of  the  form  F  h  e  :  r,  where  F  is  a  type  assignment  and  e  is  a  Age 
expression.  We  use  “h”  instead  of  “[>”  to  keep  from  confusing  these  typing  judgements  with  the 
Age-mono  and  Age-poly  judgements. 


Expressions: 


(var) 


(tuple) 

(fn 


r  1+)  {x:t}  b  X  :  t 

r  h  ei  :  ri  F  h  62  :  r2 
r  h  (£1,62)  :  ri  X  r2 

r  1+)  {x:ti  }  h  e  :  72 


(int) 


r  h  2  :  int 


r  f-  Xx.e  :  Ti  T2 
Heaps  and  Programs: 


(app) 


,  r  1-  e  :  Ti  X  r2 

(proj)  — - -  [i  =  1,2) 

i  r  TTi  e  :  Tj 

r  b  Cl  ;  ri  — )■  r2  F  b  £2  :  ri 

F  b  Cl  eo  :  To 


(heap) 


Wxe  Dom{T') .  F  W  F'  b  H{x)  :  F'(a;) 
F  b  :  F' 


(prog) 


0bi7:F  Fbe:r 
b  letrec  iJ  in  e  :  t 


Figure  7:  Type  Inference  Rules  for  Age 


A  given  Age  expression  can  have  multiple  typing  derivations  according  to  these  rules  and  con¬ 
sequently  multiple  typings,  but  an  expression’s  typings  may  be  ordered  so  that  there  is  a  most 
general,  or  principal  typing  and  every  other  typing  is  an  instance  of  this  principal  typing  and  is 
thus  derivable.  The  ordering  is  defined  in  terms  of  a  substitution: 

Definition  6.1  (Substitution)  A  substitution  S  is  a  function  from  type  variables  to  type  expres¬ 
sions. 

We  write  5r  to  denote  the  type  obtained  by  replacing  each  type  variable  t  in  r  with  S{t)  and 
we  write  5F  to  denote  the  type  assignment  {x:5r  |  x:t  £  F). 

Definition  6.2  (Instance,  Subsumes,  Principal  Typing)  A  typing  F'  b  e  :  r'  is  an  instance 
of  the  typing  V  b  e  :  t  if  there  exists  a  substitution  S  such  that  5F  C  F'  and  Sr  =  r'.  In  such  a 
case,  we  say  that  (F,  r)  subsumes  (F',  r').  A  typing  T  b  e  :  r  is  principal  if  for  all  other  typings 
F'  b  e  :  t' ,  (F,r)  subsumes  (F',r'). 

A  consequence  of  the  definition  of  a  principal  typing  is  that  any  instance  of  the  principal  typing 
is  derivable: 

Lemma  6.3  If  (F,  r)  is  a  principal  typing  for  e,  then  for  all  substitutions  S ,  ST  b  e  ■.  St. 

It  is  straightforward  to  see  that  principal  typings  for  Age  expressions  are  unique  (up  to  a- 
conversion  of  type  variables) .  Consequently,  we  can  search  for  the  principal  typing  of  a  Age  program 
in  order  to  determine  if  there  is  any  typing  derivation  of  a  program.  The  critical  component  of  a 
type  inference  algorithm  is  an  algorithm  for  unifying  types  and  type  assignments: 
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Definition  6.4  (Unifier,  Most  General  Unifier)  A  unifier  of  a  set  of  type  equations  E  is  a 
substitution  S  such  that  for  all  ti  =  r2  £  E,  Sti  is  syntactically  equal  to  St2.  A  unifier  S  of  E  is 
more  general  than  Sx  if  there  exists  a  unifier  S2  such  that  Si  =  S2  o  S . 

Lemma  6.5  (Unification)  [31]  Let  E  be  a  set  of  type  equations.  There  is  an  algorithm  Unify{E) 
that  computes  a  most  general  unifier  of  E  if  one  exists  and  fails  otherwise. 

If  Fi  and  r2  are  type  assignments,  then  the  unification  algorithm  can  be  used  to  compute 
a  most  general  substitution  5  such  that  SFi  U  5r2  is  well  formed,  if  such  a  substitution  exists. 
(Recall  that  a  well  formed  type  assignment  maps  term  variables  to  at  most  one  type.)  We  simply 
compute  Unify{E)  where  E  —  {ri  =  r2  |  x:ti  £  Fi  and  x'.T2  £  F2}.  We  write  l7n2y?/(Fi,  F2)  for  the 
substitution  obtained  in  this  manner. 


PT{x) 

=  {{x.t},t) 

[t  fresh) 

PT{i) 

=  (0,int) 

PTi{ex,e2)) 

=  let(ri,ri)  =  PTiex) 

in  let  (42, r2)  =  RT(e2) 

in  let  5  =  UnifyiTx,V2) 

in(5ri  U5r2,5ri  x  8x2) 

PT{wi  e) 

=  let(r,r)  =  PT{e) 

in  let  S  =  Unify({x\T},{x-ix  x  U}) 

{tx,t2  fresh) 

in  iSV,Sti) 

PTiXx.e) 

=  Iet(r,rixr2)  =  PT({x,e)) 

in  (r  \  {x:rx},Tx  T2) 

PTiex  62) 

=  let(ri,ri)  =  PT(ei)  in  let  (r2,r2)  =  Pr(e2) 

in  let  5  =  {7nz/j/(ri  W  {x:ri},  42  W  {a::r2  — >■  t}) 

(a;,  t  fresh) 

in  (54i  U ST2,St) 

PTA{e) 

=  let  (4,r)  =  Pr(e)  in  4 

PTT{e) 

let  (4,  r)  =  PT(e)  in  r 

Figure  8:  An  Algorithm  for  Computing  the  Principal  Typing  of  an  Expression 


Given  a  Age  expression  e,  the  algorithm  PT{e)  in  Figure  8  computes  the  most  general  type 
assignment  and  type  for  that  expression.  The  algorithm  is  similar  to  the  MTA  algorithm  of  Sec¬ 
tion  5.4,  but  uses  the  Unify{-]  routine  to  compute  most  general  substitutions  that  allow  two  type 
assignments  to  be  merged.  The  variable  case  returns  a  type  assignment  mapping  the  variable  to  a 
fresh  type  variable  and  returns  that  type  variable  as  the  type  of  the  expression.  The  integer  case 
returns  an  empty  type  assignment  and  the  integer  type.  The  tuple  case  computes  the  principal  typ¬ 
ings  of  the  components  of  the  tuple,  and  then  computes  a  unifying  substitution  of  their  respective 
type  assignments.  This  step  is  necessary  because  the  same  variable  could  occur  within  two  different 
components,  and  the  types  of  these  two  occurrences  must  unify.  The  substitution  is  applied  to  each 
component’s  principal  type  assignment  and  the  union  of  the  resulting  assignments  is  returned  as 
the  principal  assignment  of  the  tuple.  The  type  is  calculated  by  applying  the  substitution  to  each 
of  the  components’  principal  types  and  then  forming  a  tuple  type.  The  type  of  an  abstraction 
Xx.e  is  calculated  by  finding  the  principal  typing  of  the  expression  {x,e).  The  type  of  the  resulting 
expression  contains  the  domain  type  of  the  abstraction  paired  with  the  range  type.  The  pairing  is 
needed  since  x  may  not  occur  in  e  and  thus  may  not  occur  in  the  resulting  type  assignment  F.  The 
principal  type  assignment  of  the  abstraction  is  simply  F  minus  the  occurrence  of  x:ti. 
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The  following  lemma  establishes  the  key  properties  of  PT{e): 

Lemma  6.6  If  PT{e)  =  (r,r),  then  F  h  e  :  r.  Furthermore,  ifT'he-.r'  for  some  F'  and  t' ,  then 
PT{e)  exists  and  PT[e)  subsumes  (F',r'). 

The  algorithm  for  determining  the  principal  typing  of  an  expression  can  be  easily  extended 
to  find  a  principal  typing  for  a  heap  and  a  program.  The  former  returns  a  principal  pair  of 
type  assignments  (F,F/f)  for  H,  such  that  T  H  :Th  and  the  latter  returns  the  principal  type 
assignment  and  type  for  the  program: 

PT{{x,  =  h,,...,Xn^h^})  =  let  (Fi,ri)  :=  Pr(/ii)  •••  (F„,r„)  =  Pr(e„) 

in  let  F  =  {arjiri,  •  •  • , 
in  let  5  =  C/m/t/(F,  Fi,  •  •  •,  F„) 
in  ((5FiU---U5F„)\5F,5F) 

Pr(ietrec  H  \n  e)  =  let  (F,F//)  =  PT{H) 

inlet(F„r)=  Pr(e) 

in  let  S  =  Unify{V  1+)  F//,  Fe) 
in  (5Fu(5Fe\5FH),5r) 

The  following  lemma  shows  that  PT{P)  computes  the  principal  type  for  a  program  and  that  any 
typing  for  the  program  is  an  instance  of  the  principal  typing. 

Lemma  6.7  If  PT{P)  =  (F,r),  then  F  h  P  :  r.  Furthermore,  ifT'\-P:  t' ,  then  (F,  r)  subsumes 

(r',rO. 

The  algorithm  is  complete  in  that  if  there  exists  some  typing  for  the  program,  then  the  algorithm 
will  not  fail  to  find  the  principal  typing  of  the  program. 

Lemma  6.8  IfT\-P:T,  then  PT{P)  exists. 

Finally,  soundness  for  the  static  semantics  follows  by  showing  that  principal  typings  of  a  program 
are  preserved  by  evaluation. 

Theorem  6.9  (Type  Soundness)  If  P  then  either  P  is  an  answer  or  else  there  exists  a  P' 
such  that  P  P'  and  h  P' . 

6.2  The  Inference  GC  Specification 

We  will  show  that  if  we  can  find  a  typing  for  a  program  that  assigns  a  location  bound  in  the 
heap  a  type  variable,  then  that  location  may  be  bound  to  any  value  without  affecting  evaluation. 
Consequently,  any  pointers  contained  in  the  location’s  binding  do  not  need  to  be  scanned  and 
traced  during  garbage  collection.  The  intuition  behind  the  theorem  is  that  a  location’s  type  is 
unconstrained  only  if  the  location  is  not  applied  nor  projected  nor  used  in  some  manner  that  would 
constrain  the  type.  Consequently,  we  can  replace  the  binding  in  the  heap  with  any  binding  we 
choose.  In  particular,  if  the  location  is  bound  to  a  large  heap  value,  we  can  bind  the  location  to  an 
integer  or  dummy  piece  of  code  without  affecting  evaluation.  This  replacement  allows  us  to  collect 
any  bindings  that  used  to  be  reachable  through  this  binding  without  knowing  anything  about  the 
shape  of  the  original  heap  value. 

The  proof  of  the  theorem  relies  upon  the  semantic  interpretation  of  types  as  logical  relations.  In 
our  case,  the  relations  are  a  type-indexed  family  of  binary  relations  relating  programs  to  programs, 
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answers  to  answers,  and  heaps  to  heaps.  The  relations  are  contrived  so  that,  if  two  programs 
are  related,  then  they  are  Kleene  equivalent,  so  one  program  converges  to  an  answer  iff  the  other 
converges  to  a  related  answer  and  related  answers  at  base  type  (int)  yield  equal  values.  Roughly 
speaking,  the  relations  are  logically  extended  to  relate  answers  of  higher  type  (^)  if,  whenever 
such  answers  are  applied  to  appropriately  related  answers,  the  resulting  computations  yield  related 
results. 

The  relations  are  defined  in  Figure  9  by  induction  on  types.  The  definitions  are  parameterized 
by  an  arbitrary  relational  interpretation  of  type  variables,  0.  If  t  is  a  type  variable,  then  0(t) 
determines  some  fixed,  but  arbitrary  relation  between  answer  programs.  This  is  consistent  with 
the  idea  that  well- typed  programs  have  an  implicit  “V”  quantifier  for  the  type  variables  in  a  program. 
The  parameterization  of  the  interpretation  of  type  variables  makes  it  straightforward  to  extend  the 
definition  of  the  relations  to  account  for  predicative  polymorphism. 


Computations: 


Q  \=  P\  ~  P2  '■  T  iff  H  Pi  :  r  and  h  P2  :  r  and 

Pi  -D-ii  ^1  implies  P2  A2  and  0  |=  >li  «  T2  :  n 
and 

P2  -tlii  A2  implies  Pi  JJ-n  Ai  and  Q  \=  Ai  Ki  A2  :  r 


Answers: 

0  1=  Ai  w  A2  :  <  iff  (Ai,A2)e0(t) 

0  ^  letrec  Hi  in  xi  letrec  H2  in  X2  '  int  iff  Hi{xi)  =  H2{x2)  =  i 

0  ^  letrec  Hi  in  a:i  letrec  H2  in  X2  '■  ti  x  T2  iff  0  1=  letrec  Hi  in  tti  xi  ~  letrec  H2  in  ;ri  X2  ■  ti 

and 

0  ^  letrec  Hi  in  7r2  Xi  ~  letrec  H2  in  7r2  X2  :  T2 

0  j=  letrec  Hi  in  xi  «  letrec  H2  in  X2  '■  n  -i-  T2  iff  VPJ,  H2,yi,y2- 

0  1=  letrec  P'1  t+l  in  yi  ss  letrec  H2  W  P2  m  2/2  :  ’’’i 
implies 

0  1=  letrec  Hi  0  H[  in  a;i  yi  ~ 

letrec  H2^  H2  '\n  X2  y2  ■  ^2 


Heaps: 

0  1=  Pi  w  P2  :  r  iff  0  h  Pi  :  r  and  0  h  P2  :  r  and 

Vr  G  Dom{T).Q  [=  letrec  Pi  in  r  w  letrec  P2  in  r  :  r(x) 

Figure  9:  Relational  Interpretation  of  Types 


Two  well- typed  programs  Pi  and  P2  are  related  at  a  type  r,  written  Q  \=  Pi  P2  :  r  iS, 
whenever  one  of  the  programs  terminates  with  an  answer,  then  the  other  program  terminates  with 
a  related  answer  at  type  r. 

Two  answer  programs  Ai  and  A2  are  related  at  type  r,  written  0  [=  Ai  A2  :  r,  as  follows: 
If  r  is  a  type  variable  t,  then  the  answers  are  related  iff  they  are  in  the  relation  0(t).  If  t  is  an 
integer,  then  the  answers  are  related  iff,  when  we  lookup  the  answer  variables  in  their  respective 
heaps,  they  are  bound  to  the  same  integer  value.  If  r  is  a  pair,  then  the  answers  are  related  iff, 
whenever  we  project  a  component,  the  resulting  programs  are  related.  Finally,  if  r  is  an  arrow  type 
Ti  T2,  the  answers  are  related  iff,  whenever  we  apply  the  answer  variables  to  related  arguments 
at  type  ri,  we  get  related  programs  at  type  T2.  Even  though  the  relations  between  programs  and 
answers  are  defined  in  terms  of  one  another,  the  relations  are  well-founded  because  the  size  of  the 
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type  index  always  decreases  when  one  relation  refers  to  another. 

The  definition  of  the  relations  ensures  that  related  programs  remain  related  even  if  more  bindings 
are  added  to  the  programs’  heaps. 

Lemma  6.10  //  0  [=  letrec  Hi  in  ej  ~  letrec  H2  in  62  :  r  and  h  letrec  Hi  H[\r\  e  :  t  and 
h  letrec  H2  ^  H2  In  e  :  t,  then  0  |=  letrec  Hi^i^  H[  in  e  ~  letrec  H2^  H2  \n  e  :  r. 

Since  evaluation  only  adds  new  bindings  and  leaves  existing  bindings  intact,  it  is  clear  that  evalu¬ 
ation  preserves  the  relations.  If  the  language  permitted  assignment,  then  this  property  would  not 
necessarily  hold. 

For  the  statement  of  the  following  lemma,  we  need  to  extend  the  answer  relation  to  heaps.  Two 
heaps.  Hi  and  jH'2,  are  related  at  a  context  F,  written  0  |=  i?2  :  F,  if  they  can  be  a-converted 

so  that,  for  all  variables  x  in  F,  the  answers  letrec  Hi  in  x  and  letrec  H2  in  x  are  related  at  r(x). 

The  following  lemma  establishes  our  primary  result:  an  expression  is  related  to  itself  in  the 
context  of  any  two  related  heaps. 

Lemma  6.11  For  all  0  :  Tvar  [Ans  -H-  Ans),  F  F  e  :  r  and  Q  \=  Hi  ^  H2  :  T,  then 
0  1=  letrec  iFi  in  e  ~  letrec  H2  in  e  :  r. 

Proof:  By  induction  on  the  derivation  of  F  F  e  :  r. 
var:  (F  1+)  {a;:r}  x  :  r)  By  the  definition  of  ©  |=  iFi  «  F/'2  :  F. 

int:  (F  h  i :  int)  letrec  Hj  in  i  1-^  letrec  Hj  l+l  {xj  =  f}  in  Xj  for  j  =  1,2  and  these  two  answers  are  related 
by  the  definition  of  0  ^  Ti  «  A2  :  int. 

tuple:  (F  h  (61,62)  :  n  X  r2)  Suppose  letrec  Hi  in  (61,62)  does  not  diverge.  Then  by  examination  of  the 
rewriting  rules,  it  is  clear  that: 

letrec  Hi  in  (ei,  62)  letrec  iFi  1+)  Ffi  l+l  {a:i  =  hi}  in  (xi,  62)  1-^* 

letrec  iFi  i+)  l+l  {a;i  =  hi}  l+l  H"  i+l  {2:2  =  ^*2}  in  (xi,  X2)  1-^ 

letrec  ifi  l+l  t±i  {ii  =  hi}  l+l  H”  l+l  {x2  =  h2}  l+l  {x  =  (xi,  2:2)}  in  x 

Thus,  letrec  Hi  in  61  t-^*letrec  ifi  l+l//(  l+l{xi  =  hi}  in  Xi.  By  the  induction  hypothesis  applied  to  the 
first  hypothesis  of  the  pair  rule,  we  conclude  that  letrec  1^2  in  61  letrec  H2^  Hly^i)  {x[  =  h(}  in  x'l 
and  these  two  answers  are  related.  Consequently,  letrec  H2  in  (61,62)  1-^  ‘letrec  H2^  H2^  {x'l  = 
h(}  in  (x'l,  62). 

From  the  rewriting  sequence  above,  we  can  conclude  that  letrec  iFi  l+l  l+l  {xi  =  hi}  in  62 
‘letrec  hfi  l+l  l±l  {xi  =  hi}  l+l  if"  l+l  {2:2  =  h2}  in  2;2-  By  hypothesis,  0  |=  iii  «  ii'2  :  F  and  thus  by 

Lemma  6.10  ©  |=  ifi  W  if(  l±l  {xi  =  hi}  w  H2^H2^  {x2  —  h^}  :  F,  so  the  induction  hypothesis  applies 

to  the  second  hypothesis  of  the  pair  rule  and  we  can  conclude  that  letrec  ifoWFf^Fix'i  =  h'l}  in  62 
‘letrec  H2  l±l  hi^  W  {2^1  =  h'l}  l+l  H2  l±l  {x^  =  h^}  in  Xj  and  these  two  answers  are  related.  Consequently, 
letrec  H2'S  Hl^'S  {x'j  =  h'l}  in  (x'1,62)  1-^ ‘letrec  if  2  ©  i?^  hi  {x'j  =  h'l}  ©  if,  ©  {x',  =  hj}  in  (x},  x',). 
Since  related  answers  remain  related  under  heap  extensions, 

0  1=  letrec  ifi  ©  if{  ©  if"  ©  {xi  =  hi,X2  —  h2,  x  =  (xi,  X2,  })  in  x,-  « 

letrec  H2  ©  if 2  ©  H2  ©  {x'l  =;  h(,  X2  =  h'2,  x'  =  (x},  X2,  })  in  xJ  :  p-  {i  =  1,  2) 

Consequently, 

0  t=  letrec  ffi  ©  ff(  W  if"  W  {xi  =  hi,  X2  =  h2,  x  =  (xi,  X2,  })  in  tt,-  x  ~ 

letrec  if2  ©  if^  ©  if,  ©  {x}  =  h^,  X2  =  h^,  x'  =  (x},  xi,  })  in  tt,  x'  :  r,-  (i  —  1,2) 

Thus,  0  [=  letrec  Hi  in  (61,62)  ~  letrec  Ho  in  (61,62)  :  Ti  x  r2. 
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proj:  (r  h  TTi  e  :  r,)  Suppose  letrec  Ei  in  e  converges.  Then, 

letrec  ffi  in  tt;  e  i-^’letrec  Ei  1+)  E'l  in  TTi  x  letrec  Hi  H[\n  y 

for  some  H'l,  x,  and  y.  Thus,  letrec  Hi  in  e  ’letrec  Hi  W  H'l  in  x.  By  the  induction  hypothesis, 
letrec  H2  in  e  ’letrec  H2  W  H2  in  x'  and  0  [=  letrec  Hi^S  H'l'xn  x  k  letrec  H2  W  H'o  in  x'  :  Ti  x  To. 
By  the  definition  of  this  relation,  we  know  that 

0  1=  letrec  Hi  l±l  H'l  in  tTj-  x  ~  letrec  H2  W  H2  in  tt;  x'  :  Ti  x  T2 

for  i  =  1,  2.  Thus,  0  |=  letrec  Hi  in  tt,  e  ~  letrec  H2  in  rrj  e  :  ri  x  r2. 

fn:  (r  h  Xx.e  :  n  r2)  letrec  Hi  in  Xx.e  letrec  Hi  1+)  {pi  =  Xx.e)  in  j/,-  for  i  =  1,  2.  We  must  show  that 
these  two  answers  are  related.  Suppose: 

0  t=  letrec  Hi  W  {yi  =  Xx.e}  l+l  H[  in  zi  «  letrec  Hi  1+)  {j/2  =  Aai.e}  1+)  H'^  in  22  :  n 
for  some  H'l,  H'^,  21,  and  22.  We  need  to  show  that: 

0  t=  letrec  Hi  W  {yi  =  As.e}  1+)  H'l  in  yi  zi  ~  letrec  Hi  l±)  {2/2  =  Ax.e}  1+)  H2  in  y2  22  :  '''2 
This  follows  if: 

0  \=  letrec  Hi  l+l  {j/i  =  Xx.e,  x  =  hi}  l+)  /fi  in  e  ~  letrec  Hi  l+l  {y2  =  Xx.e,  x  =  ^2}  'S  H'o  \r\  e  :  T2 

where  hi  -  {Hi  l+l  {yi  =  Ax.e}  l+l  H{)(zi)  for  i  =  1,2.  By  the  induction  hypothesis,  it  suffices  to  show 
that: 

0  1=  i^i  l+l  {t/i  =  Xx.e,x=  hi}  1+)  ft!  fill  1+)  {t/2  =  Xx.e,x  =  ^2}  W  :  T  l+l  {x  :  n} 

By  the  lemma’s  hypothesis,  we  know  that  0  |=  i^i  ft  i?2  :  B  and  thus  by  Lemma  6.10 
0  ^  iLi  l+l  {j/i  =  Ax.e,  X  =  hi}  W  iifj  ft  iif2  0  {2/2  =  Ax.e,  x  =  h2}  0  i?2  •  B- 

Since 

0  t=  letrec  Hi  l+l  {j/i  =  Ax.e,x  =  hi}  1+)  if}  in  21  ft  letrec  Hi  l+J  {j/2  =  Ax.e,  x  =  h2}  0  Ho  in  22  :  n 
and  hi  and  h2  are  bound  to  21  and  22  in  these  respective  heaps,  it  follows  that: 

0  1=  letrec  Hi  l+l  {yi  =  Xx.e,  x  —  hi}  1+)  if}  in  x  ft  letrec  Hi  1+)  {y2  =  Ax.e,  x  =  h2}  \t)  H2  \ri  x  :  n 
Consequently, 

0  t=  hfi  l±)  {j/i  =  Ax.e,  X  =  hi}  W  ft  i?!  1+)  {y2  =  Ax.e,  x  =  h2}  l+l  F2  :  B  l+l  {x  :  n} 
holds  and,  working  backwards  we  know  that 

0  1=  letrec  Hi  l±l  {j/i  =  Ax.e}  l+l  H}  in  yi  zi  ~  letrec  Hi  1+)  {j/2  =  Ax.e}  l±l  H2  in  j/2  ^2  '■  x'2 

and  thus  0  |=  letrec  Hi  l+J  {j/i  =  Ax.e}  in  yi  ft  letrec  H2  0  {2/2  =  Ax.e}  in  2/2  :  n  ^  '^2- 

app:  (r  b  ei  e2  :  r2)  Suppose  letrec  Hi  in  ei  62  does  not  diverge.  Then  by  examination  of  the  rewriting 
rules,  it  is  clear  that: 

letrec  Hi  in  ei  62  1-^*  letrec  hfi  l+l  l±)  {xi  =  hi}  in  xi  62  < — >* 
letrec  hfi  l+l  l+l  {xi  =  hi}  i±l  H"  1+)  {x2  =  h2}  in  xi  X2 

Thus,  letrec  Hi  in  ei  i-^’letrec  hfi l+lF( l+l{xi  =  hi}  in  xi.  By  the  induction  hypothesis  applied  to  the 
first  hypothesis  of  the  app  rule,  we  conclude  that  letrec  iB2  in  ei  letrec  H2^  H^^  {x'l  =  h[}  in  x[ 
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and  these  two  answers  are  related  at  rj  — >  T2.  Consequently,  letrec  in  ei  63  f-^’letrec  H2^  H2^ 
{2:']^  =  h'-y]  in  x'y  63. 

From  the  rewriting  sequence  above,  we  can  conclude  that  letrec  W  1+)  {xi  =  hi}  in  63  1-^ 

*  letrec  W  l+J  {xi  =  hi}  l+J  H"  l+l  {2:2  =  h2}  in  X2-  By  hypothesis,  0  |=  i/i  Ri  i?2  :  F  and  thus 

©  [=  FTi  0  FT}  l+J  {a;i  =  hi}  w  7^2  ©  ©  {x2  =  h2}  :  F,  so  the  induction  hypothesis  applies  to  the 

second  hypothesis  of  the  app  rule  and  we  can  conclude  that  letrec  Ff2  ©  FTj  ©  {x'y  =  h}}  in  62 

*  letrec  F/'2©Fr2©{a;'i  =  h}}©/!",  ©{2^2  =  ^2}  '>1  ^'2  these  two  answers  are  related  at  ri.  Consequently, 

letrec  Ff2  ©  FT,  ©  {x'y  =  h}}  in  x'y  62  •-^’'letrec  iF2  ©  Ff^  ©  {ar'i  =  h}}  ©  H2  ©  =  ^2}  ^2- 

Since 

0  j=  letrec  Ffi  ©  Ff}  ©  {xi  =  hi}  ©  H"  ©  {2^2  =  ^2}  in  xo  ^ 

letrec  Ff2  ©  FF2  ©  {2:'i  =  h}}  ©  H2  ©  {x,  =  hj}  in  X2  ■ 

and 

0  t=  letrec  FFi  ©  Ff}  ©  {xi  =  hi}  ©  H"  ©  {x2  =  h2}  in  Xi  k 

letrec  H2  ©  FFj  ©  {x}  =  h}}  ©  FF"  ©  {x^  =  h2}  in  x}  '■  ti  T2 

by  the  definition  of  «  at  arrow-types,  it  follows  that 

0  [=  letrec  FFi  ©  FF}  ©  {2:1  =  hi}  ©  FF"  W  {x2  =  h2}  in  2;i  2:3  ~ 

letrec  FF2  ©  FF2  ©  {x}  =  h}}  ©  FFo  W  {x2  =  h2}  in  x'y  x'^  :  T2 

Thus,  0  1=  letrec  U\  in  ei  63  ~  letrec  FF2  in  ei  63  :  X2. 

□ 

Our  goal  is  to  shotv  that  if  we  are  given  a  context  F,  expression  e,  and  heap  B.  such  that 
r  h  e  :  r  and  0  h  FF  :  F,  then  letrec  FF'  in  e  is  Kleene  equivalent  to  letrec  FF  in  e  where  FF'  is  defined 
as  follows: 

FF'  =  {x  =  FF (x)  I  F(x)  ^  Tvar}  ©  {x  =  0  |  F(x)  6  Tvar] 

This  follows  from  Lemma  6.11  if  we  can  show  that,  taking  0o(O  to  be  the  everywhere-defined 
relation  on  answer  programs,  0o  1=  FF  «  FF'  :  F.  This  in  turn  follows  if  we  can  show  that 
00  [=  FF  «  FF  :  F  (FF  is  related  to  itself),  since  0o(F)  relates  every  program  and  FF'(x)  differs  from 
FF(x)  only  when  F(x)  =  t. 

Unfortunately,  we  cannot  directly  show  that  a  well  formed  heap  is  related  to  itself!  The  problem 
is  that  if  we  attempt  to  argue  by  induction  on  the  derivation  of  0  h  FF  :  F,  the  uses  of  the  heap 
rule  require  that  we  assume  what  we  are  trying  to  prove.  The  same  problem  is  encountered  when 
using  logical  relations  to  reason  about  conventional  calculi  with  recursion  or  iteration  operators. 

If  we  forbid  cycles  in  the  heap,  then  we  can  transform  the  derivation  of  the  heap’s  well  formedness 
into  a  derivation  that  only  uses  a  let-style  rule  instead  of  the  recursive  letrec-style  heap  rule: 


(let-heap) 


Fi  ©  F2  F  ft  :  r  Fj  F  FF  :  F2 
Fi  F  FF  ©  {x  =  ft}  :  F2  ©  {x:r} 


Consequently,  if  a  heap  is  cycle  free,  we  may  show  by  induction  on  the  derivation  using  the  let-heap 
rule  that  the  heap  is  related  to  itself. 


Lemma  6.12  F/FiFFF  :F2,0|=FFiSsFF2:Fi  and  H  is  cycle  free,  then  0}=FFi©FFrsFF2©FF: 

Fi  ©  F2. 


Proof:  Since  FF  is  cycle  free,  there  exists  some  derivation  of  Fi  F  FF  :  F  using  only  the  let- 

heap  rule.  The  proof  proceeds  by  induction  on  the  height  of  this  derivation.  If  FF  is  empty, 
then  the  lemma  holds  trivially  by  the  assumptions  about  Hi  and  FF2.  Suppose  Fi  F  FF  :  F2 
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and  Fi  i+J  r2  1“  :  T.  By  induction,  Q  \=  Hi^S  H  ~  H2^  H  :  Fi  l±)  F2.  By  Lemma  6.11, 

0  1=  letrec  iFi  l+)  iF  in  ~  letrec  iF2  W  FT  in  /i  :  r.  Thus, 

0  1=  letrec  Hi  l+J  H  \+S  {x  =  h}  in  x  ^  letrec  H2^  H  \S  {x  =  h}  in  x  :  t. 

Consequently,  0  \:^  Hi  'S  H  ^  {x  =  h}  ^  H2  ^  H  {x  =  h}  :  T i  [t)  r2  ^  {x:t }.  □ 

Finally,  we  can  state  and  prove  the  following  Inference  GC  specification; 

Theorem  6.13  (Inference  GC)  Let  Fi  =  {xiiti, . . . ,  Xn'.tn}  and  Hi  =  {xi  =  =  /i„} 

and  H'l  =  {xi  =  0, . . . ,  a;„  =  0}.  If 

1.  Fi  0  F2  F  e  :  r  (t  ^  Tvar ),  and 

2.  Ti\-  H2  ■T2,  and 

3.  35.0  FFFi  :5Fi,  and 
I  H2  is  cycle  free, 

then  letrec  iLi  0  5^2  e  ~  letrec  H[  0  H2  in  e. 

Proof:  Taking  0o(f)  to  be  the  everywhere  defined  relation,  0o  |=  iFi  ~  :  Fj  holds  trivially.  By 

Lemma  6.12,  since  H2  is  cycle  free  and  Fi  H  iL2  :  r2,  we  know  that  0o  [=  iLi0iF2  ~  H'iii)H2  '■  Fi0F2- 
Since  Fj  0  F2  F  e  :  r,  we  know  by  Lemma  6.11  that  0o  [=  letrec  Hi  'S  H2  in  e  ~  letrec  0 
F2  in  e  :  r.  Thus,  letrec  Hi  ^  H2  in  e  li-  letrec  Ha  in  x  iff  letrec  0  iL2  in  e  JJ-  letrec  Hh  in  y 
and  00  1=  letrec  Ha  in  x  w  letrec  Hf,  in  y  :  r.  Suppose  Ha{x)  =  i  (or  Lff,(y)  =  *)•  Then  r 
must  be  int  since  r  ^  Tvar.  By  the  definition  of  «  at  int,  Hb{y)  =  i  (or  Ha{x)  =  i).  Thus, 
letrec  LFi  0  iF2  in  e  —  letrec  H[  0  H2  in  e.  D 

It  should  be  possible  to  extend  our  argument  to  cyclic  heaps  if  we  can  show  that  every  cyclic  heap 
is  appropriately  approximated  by  some  finite  “unwinding”  of  the  heap.  One  approach  is  to  use  a 
fixed-point  semantics  for  Age  where  types  are  interpreted  as  CPOs  formed  by  suitably  lifting  answer 
programs.  The  meaning  of  an  answer  program  letrec  if  in  a;  would  essentially  be  the  least  fixed- 
point  of  the  chain  of  meanings  of  the  approximations  letrec  H°  in  a;, letrec  H^  in  x, letrec  H^  in  x,. . . 
where  LP'  denotes  the  unwinding  of  the  heap  H.  See  Gunter  [17,  Chapter  4.4]  for  an  example 
of  the  treatment  of  unwinding  and  approximation  in  the  context  of  a  conventional  A-calculus. 

7  Related  Work 

The  literature  on  garbage  collection  in  sequential  programming  languages  per  se  contains  few  papers 
that  attempt  to  provide  a  compact  characterization  of  algorithms  or  correctness  proofs.  Demers  et 
al.  [10]  give  a  model  of  memory  parameterized  by  an  abstract  notion  of  a  “points-to”  relation.  As  a 
result,  they  can  characterize  reachahility-hd&ed  algorithms  including  mark-sv/eep,  copying,  genera¬ 
tional,  “conservative,”  and  other  sophisticated  forms  of  garbage  collection.  However,  their  model  is 
intentionally  divorced  from  the  programming  language  and  cannot  take  advantage  of  any  semantic 
properties  of  evaluation,  such  as  type  preservation.  Consequently,  their  framework  cannot  easily 
model  the  type-based  collectors  of  Sections  5  and  6.  Nettles  [27]  provides  a  concrete  specification 
of  a  copying  garbage  collection  algorithm  using  the  Larch  specification  language.  Our  specification 
of  the  free- variable  tracing  algorithm  is  essentially  a  high-level,  one-line  description  of  his  specifica¬ 
tion.  Like  Demers  et  al,  he  uses  a  traditional  definition  of  garbage  based  on  unreachability  in  the 
memory  graph  and  purposefully  distances  the  specification  from  any  language  evaluation  details. 
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Hudak  gives  a  denotational  model  that  tracks  reference  counts  for  a  first-order  language  [20]. 
He  presents  an  abstraction  of  the  model  and  gives  an  algorithm  for  computing  approximations  of 
reference  counts  statically.  Chirimar,  Gunter,  and  Riecke  give  a  framework  for  proving  invariants 
regarding  memory  management  for  a  language  with  a  linear  type  system  [9].  Their  low-level 
semantics  specifies  explicit  memory  management  based  on  reference  counting.  The  goal  of  the 
work  was  to  determine  whether,  using  the  linear  type  system,  in-place  update  would  be  a  sound 
optimization.  Both  Hudak  and  Chirimar  et  al.  assume  a  fairly  weak  approximation  of  garbage 
(reference  counts). 

Tolmach  [34]  built  a  type-recovery  collector  for  a  variant  of  SML  that  passes  type  information 
to  polymorphic  routines  during  execution,  effectively  implementing  our  Agc-poly  language  and  the 
corresponding  collector  of  Subsection  5.5.  Aditya  and  Caro  gave  a  type-recovery  algorithm  for  an 
implementation  of  Id  that  uses  a  technique  that  appears  to  be  equivalent  to  type  passing  [1]  and 
Aditya,  Flood,  and  Hicks  extended  this  work  to  garbage  collection  for  Id  [2]. 

There  have  been  a  variety  of  papers  regarding  inference-based  collection  for  monomorphic  [7,  36, 
8]  and  polymorphic  languages  [3,  15,  16,  12].  Appel  [3]  argued  informally  that  “tag-free”  collection 
is  possible  for  polymorphic  languages  such  as  SML  by  a  combination  of  recording  information 
statically  and  performing  what  amounts  to  type  inference  during  the  collection  process,  though  the 
connections  between  inference  and  collection  were  not  made  clear.  Baker  [6]  recognized  that  Milner- 
style  type  inference  can  be  used  to  prove  that  reachable  objects  can  be  safely  collected,  but  did  not 
give  a  formal  account  of  this  result.  Goldberg  and  Gloger  [16]  recognized  that  it  is  not  possible 
to  reconstruct  the  concrete  types  of  all  reachable  values  in  an  implementation  of  an  ML-style 
language  that  does  not  pass  types  to  polymorphic  routines.  They  gave  an  informal  argument  based 
on  traversal  of  stack  frames  to  show  that  such  values  are  semantically  garbage.  Fradet  [12]  gave 
another  argument  based  on  Reynolds’  abstraction/parametricity  theorem  [29].  Fradet’s  formulation 
is  closer  to  ours  than  Goldberg  and  Gloger’s,  since  he  represented  the  evaluation  “stack”  as  a  source- 
language  term.  However,  none  of  these  papers  gives  a  complete  formulation  of  the  underlying 
dynamic  and  static  semantics  of  the  language  and  thus  the  proofs  of  correctness  are  necessarily  ad 
hoc. 

Finally,  Purushothaman  and  Seaman  [28,  32]  and  Launchbury  [21]  have  proposed  “natural” 
semantics  for  call-by-need  (lazy)  languages  where  the  semantic  objects  include  an  explicit  heap. 
This  allows  sharing  and  memoization  of  computations  to  be  expressed  in  the  semantics.  More 
recently,  Ariola  et  al.  [5]  (see  also  [4,  22])  have  presented  a  purely  syntactic  theory  of  the  call-by¬ 
need  A-calculus  that  is  largely  compatible  with  our  work. 

8  Summary 

Our  paper  provides  a  unifying  semantic  framework  for  a  variety  of  garbage  collection  ideas  includ¬ 
ing  standard  copying  and  mark-sweep  collection,  generational  collection,  tag-free  collection,  and 
inference-based  collection.  By  making  allocation  and  the  heap  explicit,  we  are  able  to  reason  about 
memory  management  using  traditional  A-calculus  techniques.  In  particular,  we  are  able  to  make 
strong  connections  between  garbage  collection  and  type  theory.  By  abstracting  away  such  low-level 
details  as  evaluation  stacks,  registers,  and  addresses,  we  are  able  to  formulate  complicated  collec¬ 
tion  algorithms  in  a  compact  manner  and  yet  give  a  formal  proof  of  correctness.  The  framework  is 
reasonably  robust,  as  demonstrated  by  the  breadth  of  topics  covered  in  this  paper,  and  we  expect 
that  the  framework  can  be  extended  to  deal  with  other  work  on  garbage  collection. 


30 


9  Acknowledgements 

Thanks  to  Edo  Biagoni,  Andrzej  Filinski,  Mark  Leone,  Scott  Nettles,  Chris  Okasaki,  and  Jean¬ 
nette  Wing  for  proofreading  earlier  drafts  of  this  document  and  for  providing  valuable  insight. 

This  manuscript  is  submitted  for  publication  with  the  understanding  that  the  U.S.  Government  is 

authorized  to  reproduce  and  distribute  reprints  for  Governmental  purposes,  notwithstanding  any 

copyright  notation  thereon. 

References 

[1]  S.  Aditya  and  A.  Caro.  Compiler-directed  type  reconstruction  for  polymorphic  languages.  In  Proceedings 
of  the  Conference  on  Functional  Programming  Languages  and  Computer  Architecture,  pages  74-82, 
Copenhagen,  Denmark,  June  1993. 

[2]  S.  Aditya,  C.  Flood,  and  J.  Hicks.  Garbage  collection  for  strongly- typed  languages  using  run-time  type 
reconstruction.  In  Proceedings  of  the  1994  ACM  Conference  on  Lisp  and  Functional  Programming, 
pages  12-23,  June  1994. 

[3]  A.  W.  Appel.  Runtime  tags  aren’t  necessary.  Journal  of  Lisp  and  Symbolic  Computation,  2:153-162, 
1989. 

[4]  Z.  M.  Ariola  and  M.  Felleisen.  The  call-by-need  lambda  calculus.  Technical  Report  CIS-TR-94-23, 
University  of  Oregon,  Oct.  1994. 

[5]  Z.  M.  Ariola,  M.  Felleisen,  J.  Maraist,  M.  Odersky,  and  P.  Wadler.  A  call-by-need  lambda  calculus.  In 
Conference  Record  of  the  22nd  Annual  ACM  Symposium  on  Principles  of  Programming  Languages,  San 
Francisco,  CA,  Jan.  1995. 

[6]  H.  Baker.  Unify  and  conquer  (garbage,  updating,  aliasing  ...)  in  functional  languages.  In  Proceedings 
of  the  1990  ACM  Conference  on  Lisp  and  Functional  Programming,  pages  218-226,  1990. 

[7]  P.  Branquart  and  J.  Lewi.  A  scheme  for  storage  allocation  and  garbage  collection  for  Algol-68.  In 
Algol-68  Implementation.  North-Holland  Publishing  Company,  Amsterdam,  1970. 

[8]  D.  E.  Britton.  Heap  storage  management  for  the  programming  language  Pascal.  Master’s  thesis, 
University  of  Arizona,  1975. 

[9]  J.  Chirimar,  C.  A.  Gunter,  and  J.  G.  Riecke.  Proving  memory  management  invariants  for  a  language 
based  on  linear  logic.  In  Proceedings  of  the  1992  ACM  Conference  on  Lisp  and  Functional  Programming, 
pages  139-150,  June  1992. 

[10]  A.  Demers,  M.  Weiser,  B.  Hayes,  H.  Boehm,  D.  Bobrow,  and  S.  Shenker.  Combining  generational  and 
conservative  garbage  collection:  Framework  and  implementations.  In  Conference  Record  of  the  17th 
Annual  ACM  Symposium  on  Principles  of  Programming  Languages,  pages  261-269,  Jan.  1990. 

[11]  M.  Felleisen  and  R.  Hieb.  The  revised  report  on  the  syntactic  theories  of  sequential  control  and  state. 
Technical  Report  89-100,  Rice  University,  June  1989.  Also  appears  in:  Theoretical  Computer  Science, 
102, 1992. 

[12]  P.  Fradet.  Collecting  more  garbage.  In  Proceedings  of  the  1994  ACM  Conference  on  Lisp  and  Functional 
Programming,  pages  24-33,  June  1994. 

[13]  J.-Y.  Girard.  Une  extension  de  1 ’interpretation  de  Gddel  a  I’analyse,  et  son  application  a  I’elimination 
des  coupures  dans  I’analyse  et  la  theorie  des  types.  In  Proceedings  of  the  Second  Scandinavian  Logic 
Symposium,  edited  by  J.E.  Fenstad.  North-Holland,  Amsterdam,  pages  63-92,  1971. 

[14]  J.-Y.  Girard.  Interpretation  Fonctionnelle  et  Elimination  des  Coupures  dans  I’Arithmetique  d’Ordre 
Superieur.  PhD  thesis,  Universite  Paris  VII,  1972. 


31 


[15]  B.  Goldberg.  Tag-free  garbage  collection  for  strongly  typed  programming  languages.  In  Proceedings 
of  the  ACM  SIGPLAN  ’91  Conference  on  Programming  Language  Design  and  Implementation,  pages 
165-176,  June  1991. 

[16]  B.  Goldberg  and  M.  Gloger.  Polymorphic  type  reconstruction  for  garbage  collection  without  tags.  In 
Proceedings  of  the  1992  ACM  Conference  on  Lisp  and  Functional  Programming,  pages  53-65,  June 
1992. 

[17]  C.  A.  Gunter.  Semantics  of  Programming  Languages.  MIT  Press,  1992. 

[18]  R.  Harper.  A  simplified  account  of  polymorphic  references.  Technical  Report  CMU-CS-93-169,  School 
of  Computer  Science,  Carnegie  Mellon  University,  June  1993. 

[19]  A.  L.  Hosking,  J.  E.  B.  Moss,  and  D.  Stefanovic.  A  comparative  performance  evaluation  of  write  barrier 
implementations.  In  Proceedings  OOPSLA  ’92,  ACM  SIGPLAN  Notices,  pages  92-109,  Oct.  1992. 
Published  as  Proceedings  OOPSLA  ’92,  ACM  SIGPLAN  Notices,  volume  27,  number  10. 

[20]  P.  Hudak.  A  semantic  model  of  reference  counting  and  its  abstraction.  In  Proceedings  of  the  1986  ACM 
Conference  on  Lisp  and  Functional  Programming,  pages  351-363,  1986. 

[21]  J.  Launchbury.  A  natural  semantics  for  lazy  evaluation.  In  Conference  Record  of  the  20th  Annual  ACM 
Symposium  on  Principles  of  Programming  Languages,  Charleston,  SC,  Jan.  1993. 

[22]  J.  Maraist,  M.  Odersky,  and  P.  Wadler.  The  call-by-need  lambda  calculus  (unabridged).  Technical 
Report  28/94,  Universitat  Karlsruhe,  Fakultat  fiir  Informatik,  Oct.  1994. 

[23]  1.  Mason  and  C.  Talcott.  Reasoning  about  programs  with  effects.  In  Proceedings  of  Programming 
Language  Implementation  and  Logic  Programming,  LNCS  582.  Springer-Verlag,  1990. 

[24]  1.  Mason  and  C.  Talcott.  Equivalences  in  functional  languages  with  effects.  Journal  of  Functional 
Programming,  2(1),  1991. 

[25]  J.  C.  Mitchell.  Type  systems  for  programming  languages.  Technical  Report  STAN-CS-89-1277,  De¬ 
partment  of  Computer  Science,  Stanford  University,  1989. 

[26]  R.  Morrison,  A.  Dearie,  R.  C.  H.  Connor,  and  A.  L.  Brown.  An  ad  hoc  approach  to  the  implementation 
of  polymorphism.  ACM  Trans.  Prog.  Lang.  Syst.,  13(3):342-371,  July  1991. 

[27]  S.  Nettles.  A  Larch  specification  of  copying  garbage  collection.  Technical  Report  CMU-CS-92-219, 
School  of  Computer  Science,  Carnegie  Mellon  University,  Dec.  1992. 

[28]  Purushothaman  and  J.  Seaman.  An  adequate  operational  semantics  of  sharing  in  lazy  evaluation.  In 
Proceedings  of  the  fth  European  Symposium  on  Programming,  LNCS  582.  Springer-Verlag,  1992. 

[29]  J.  Reynolds.  Types,  abstraction,  and  parametric  polymorphism.  In  Proceedings  of  Information  Pro¬ 
cessing  83,  pages  513-523,  1983. 

[30]  J.  C.  Reynolds.  Towards  a  theory  of  type  structure.  In  Proceedings,  Collogue  sur  la  Programmation. 
Lecture  Notes  in  Computer  Science,  volume  19,  pages  408-425.  Springer-Verlag,  Berlin,  1974. 

[31]  J.  A.  Robinson.  A  machine-oriented  logic  based  on  the  resolution  principle.  Journal  of  the  Association 
for  Computing  Machinery,  12,  1965. 

[32]  J.  M.  Seaman.  An  Operational  Semantics  of  Lazy  Evaluation  for  Analysis.  PhD  thesis,  Pennsylvania 
State  University,  1993. 

[33]  P.  Steenkiste  and  J.  Hennessey.  Tags  and  type  checking  in  LISP:  Hardware  and  software  approaches. 
In  Proceedings  of  the  Second  International  Conference  on  Architectural  Support  for  Programming  Lan¬ 
guages  and  Operating  Systems  (ASPLOS-II),  pages  50-59,  Oct.  1987. 

[34]  A.  Tolmach.  Tag-free  garbage  collection  using  explicit  type  parameters.  In  Proceedings  of  the  1994 
ACM  Conference  on  Lisp  and  Functional  Programming,  pages  1-11,  June  1994. 


32 


[35]  D.  Ungar.  Generational  scavenging:  A  non-disruptive  high  performance  storage  management  reclama¬ 
tion  algorithm.  In  ACM  SIGPLAN  Software  Engineering  Symposium  on  Practical  Software  Development 
Environments,  pages  15-167,  Pittsburgh,  Pennsylvania,  Apr.  1984. 

[36]  P.  Wodon.  Methods  of  garbage  collection  for  Algol-68.  In  Algol-68  Implementation.  North-Holland 
Publishing  Company,  Amsterdam,  1970. 

[37]  A.  Wright  and  M.  Felleisen.  A  syntactic  approach  to  type  soundness.  Technical  Report  TR91-160, 
Department  of  Computer  Science,  Rice  University,  Apr.  1991. 


33 


